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(57) Abstract 

An Intranet/Intemet/Web-based data management tool that provides a common GUI enabling the requesting, customizing, scheduling 
and viewing of various types of priced call detail data reports pertaining to a customer's usage of telecommunications services. 
Hie Web-based reporting system tool comprises a novel Web-based, client-server application integrated with an operational data 
management/storage infrastructure that enables customers to access their own relevant data information timely, rapidly and accurately 
through the GUI client interface. The data management system infrastructure is designed to enable the secure. initiation, acquisition, and 
presentation of telecommunications priced call detail data reports to customer workstations (51) implementing a web browser (50). 
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INTEGRATED PROXY INTERFACE FOR WEB BASED DATA 
5 MANAGEMENT REPORTS 

The present, invention relates generally to 
information delivery systems and, particularly, to a 
novel, World Wide Web/Internet -based, 

10 telecommunications network data management reporting 

and presentation service for customers of 
telecommunications service entities. 

Telecommunications service entities, e.g., 
MCI, AT&T, Sprint, and the like, presently provide for 

15 the presentation and dissemination of customer account 

and network data management information to their 
customers predominantly by enabling customers (clients) 
to directly dial-up, e.g., via a modem, to the entity's 
application servers to access their account 

20 information, or, alternately, via dedicated 

communication lines, e.g., ISDN, T-l, etc., enabling 
account information requests to be initiated through 
their computer terminal running, for example, a 
Windows® -based graphical user interface. The requests 

25 are processed by the entity's application servers, 

which retrieves the requested customer information, 
e.g., from one or more databases, processes and formats 
the information for downloading to the client's 
computer terminal. 

30 Some types of data, e.g., "priced" call 

detail data pertaining to a customer's 
telecommunications number usage, is made available for 
customers in an aggregated or processed form and 
provided to customers, e.g., on a monthly basis. This 

35 type of data is analyzed to determine, for example, 
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asset usage and trend information necessary, which is 
required for network managers to make critical business 
decisions. As an example, the assignee 
telecommunications carrier MCI Corporation provides an 

5 MCI ServiceView ("MSV") product line for its business 

customers which includes several client- server based 
data management applications. One of these 
applications, referred to as "Perspective", provides 
call usage and analysis information that focuses on the 

10 presentation of and priced call detail data and reports 

from an MCI Perspective Data Server ("StarPR"). 
Another client- server based data management 
application, referred to as "Traffic View", focuses on 
the presentation of real time call detail data and 

15 network traffic analysis/monitor information as 

provided from an MCI Traffic view server. 
Particularly, with respect to MCI's Perspective system, 
customers are provided with their monthly priced and 
discounted raw call detail data, call detail 

20 aggregates, and statistical historical summary data. 

As such, the Perspective architecture is organized 
primarily as a batch midrange-based server data 
delivery mechanism with the data being typically 
delivered on a monthly basis, allowing for "delayed" 

25 trending, call pattern analysis , repricing and invoice 

validation based on the customer's call detail data. 
The trending, analysis, and repricing functionality is 
maintained in workstation-based software provided to 
customers for installation at customer sites on their 

30 PCS . 
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Figure 1 illustrates the current architecture 
10 for Perspective and Traffic View Systems which 
presently run on separate environments and are 
maintained independently of each other. The Star PR 
5 server provides a batch reporting mechanism focused 

primarily on providing billing data to l-800/8xx # VNET, 
Vision, and other MCI customers and is used by MCI 
customers predominantly to do internal charge backs and 
to analyze billing usage. Alternately, or in addition, 

10 the customers use the data provided to them to do call 

traffic analysis, similar to TVS. 

With specific reference to Figure 1, the data 
collected is in the form of call detail records which 
are created by various MCI/Concert switches (not shown) 

15 whenever a telephone call is attempted in the MCI 

network and which includes information about call type, 
call origination and termination locations, date and 
time, added intelligent network services, any hop 
information, product type and other relevant 

20 information about the call. The Network Information 

Concentrator ("NIC") component 15 is a network element 
that collects the CDRs and sends them to appropriate 
locations via a Global Statistical Engine 17. The 
Global Statistical Engine 17 collects the CDRs and 

25 transforms, processes, and sends them to the TVS 20. 

The TVS provides access to this data through various 
statistical reports and real time monitoring engine 22 
( "RTM" ) . 

The CDRs from are also sent to the billing 
30 system which applied billing based on call detail 

values. These "priced" CDRs are known as Billing 
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Detail Records ("BDRs") and are sent to a Perspective 
Host ("Phost") server 25. The Phost server 25 filters 
out the BDRs not pertaining to the "Perspective" 
customers, applies various transformations to the 

5 customer's raw call detail data to generate summary 

data, and generates and formats the data for the 
various Perspective customers. This data is then 
compressed, sent to a document service center ("DSC") 
and CD-ROM dispatcher ( "CDD" ) 34 entities which 

10 respectively, uncompresses the data and burns CD-ROMs 

comprising the customer's raw call detail data and 
summary data, in addition to reference files and 
possibly application software (if not previously owned) 
enabling customers to perform analysis and trending of 

15 their Perspective data. These CD-ROMs are sent to the 

customers, usually on a billing cycle or monthly basis, 
who view their data through a Perspective workstation - 
based software application residing on that customer's 
CPE, e.g., PC or workstation 36. 

20 As shown in Figure 1, the existing 

Perspective Host 25 mainframe -based data delivery 
system interfaces with all Perspective upstream feed 
systems, including billing systems and order entry, and 
processes the data, e.g., creates canned aggregates, 

25 for delivery to the document service center. 

The following upstream feed systems include: 
1) order entry information from a customer order entry 
system 19 ("CORE") and which information is used by the 
Perspective Host to determine what customer data to 

30 process and where to send it; 2) VNET and Vision 

monthly billing data feeds from a commercial billing 
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system ("NBCS") system 23; 3) a Toll-free monthly 
billing data feed from a T/F database feed 27; and, a 
Concert Virtual Network Services ("CVNS" ) product feed 
from a CVNS database 31. In order for all the CDR and 
data feed information to be processed by the Phost 
server 25, various reference files and processing rules 
are provided including: alphanumeric translation 
reference files from the NCBS billing system 23 and an 
NPA/NXX- state- city and country code lookup reference 
file originating from a calling area data base ("CADB") 
35. 

While effective for its purpose, the current data 
management and presentation architecture only provides 
customers with their priced call detail data on a 
monthly basis, usually in the form of a canned report. 
This is not sufficient for an increasing number of 
customers who, to remain competitive, are required to 
have updated and real-time access to their data to 
enable them to make their critical business decisions 
quicker. Moreover, there are a variety of independent 
data management tools and legacy reporting systems 
having disparate systems and infrastructures providing 
little or no cross application interoperability and 
data sharing, thus, requiring customers to use separate 
applications to gain access to their data. 

Furthermore , existing telecommunications 
service provider reporting systems are limited in that 
reports generated are of a narrow view, and are 
delivered at predetermined times with predetermined 
formats. These prior art reporting systems do not 
enable the generation of ad-hoc reports. Moreover, 
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legacy platforms including reporting data are reaching 
the architectural limits of scalability in terms of the 
total customers they can support, total online data 
they can present, total historical data they can keep 
and type and number of applications they can support. 

It would thus be highly desirable to provide 
a data management product that is a Web-based (Internet 
and Ilntranet) client-server application providing 
priced call detail data information to customers in a 
variety of detailed report formats comprising specific 
customer account information. 

It would additionally be highly desirable to 
provide a Web -based (Internet and Ilntranet) data 
management tool having a unique back-end infrastructure 
for a Web-based client- server application which 
provides expedient and secure data access and reporting 
services to customers at any time, from any web browser 
on any computer terminal anywhere in the world. 

The present invention is directed to a 
novel iintranet/Internet/Web-based data management 
tool that provides a common GUI enabling the 
requesting, customizing, scheduling and viewing of 
various types of priced call detail data reports 
pertaining to a customer's usage of 
telecommunications services. The 
Intranet/ Internet /Web- based reporting system tool 
comprises a novel Web -based, client- server 
application integrated with an operational data 
management /storage infrastructure that enables 
customers to access their own relevant data 
information timely, rapidly and accurately through 
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the GUI client interface. The operational database 
system infrastructure particularly is configured tc 
meet a customer's real-time data processing and 
storage requirements and is easy to deploy and 
manage, and further, ensures upward and downward 
scalability. It enables effective storage of data 
from a variety of independently developed legacy 
systems and, is readily integrated into a novel 
Web -based (Internet and Intranet) reporting system 
tool that enables customers to customize and 
directly access their own relevant data report 
information. The world wide web/Internet -based 
client -server data management and reporting tool 
employs a platform- independent , i.e., JAVA-based, 
network centric GUI client presentation layer and 
an objects/dispatcher/proxy layer access 
architecture. 

Particularly, the telecommunications data 
management /system architecture is integrated with a 
novel Web/Internet based reporting system, referred 
to as networkMCI Interact ("nMCI") . The back-end 
data management/system architecture, referred to 
herein as "StarODS" , implements a Data Warehouse 
approach to maintaining data obtained from upstream 
billing systems, i.e., priced call detail data, and 
which data may be made readily available for 
reporting on a daily basis. In this approach, 
priced call detail data is maintained in datamarts 
and operational data stores capable of meeting 
real-time processing and storage requirements. 
Particularly, these datamarts may be partitioned 
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based on various criteria, e.g., customer id, to 
enable easier management of data by providing 
scalability, and enabling more control of over 
hardware and software resources, in a cost- 
effective way. Included in this datamart approach 
is a back-end server component provided to receive 
data access requests from various users in the form 
of a report request, interactive data analysis 
request or data mining request. This server routes 
the query to the appropriate data marts, data 
warehouse or operational data store and responds to 
the requestor with the result set. 

The nMCI Interact system is a layer 
functioning to enable customers to request 
reporting functionality across the Internet. This 
report request functionality includes routing 
requests to appropriate datamarts, e.g., real-time 
reporting requests will be satisfied by real-time 
database. Additionally, the interface provides 
customers with the ability to schedule and 
prioritize reports, format report request result 
sets, and provides for load balancing, report 
request validation, query generation and execution. 
Through a common GUI, customers are enabled to 
access their own metered data; i.e., Perspective or 
usage analysis data. 

In accordance with the principles of the 
present invention, there is provided a 
Web/Internet based reporting system for 
communicating data information from an enterprise 
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intranet database to a client terminal via an 
integrated interface comprising: 

a client browser application located at the client 
terminal for enabling interactive Web based 
5 communications with the reporting system, the 

client terminal identified with a customer and 
providing the integrated interface; at least one 
secure server for managing client sessions over the 
Internet, the secure server supporting a first 
10 secure socket connection enabling encrypted 

communication between the browser application 
client and the secure server; a dispatch server for 
communicating with the secure server through a 
firewall over a second socket connection, the first 
15 secure and second sockets forming a secure 

communications link, the dispatch server enabling 
forwarding of a report request message and an 
associated report response message back to the 
client browser over the secure communications link; 
20 a report manager server for maintaining an 

inventory of reporting items associated with a 
customer and managing the reporting of customer - 
specific data information in accordance with a 
customer request message, the report manager 
25 accessing reporting items based on a customer 

identity and report name from a first database, and 
generating a response message including a metadata 
description of the reporting items; and, decision 
support server interfacing with the report manager 
30 for accessing the customer -specific data from the 

enterprise intranet database in accordance with the 
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customer identity and report name, wherein the 
retrieved data and the metadata description of the 
reporting item are utilized to generate a completed 
report for presentation to the customer via the 
5 interface. 

Advantageously, the novel Web/Internet 
based reporting system integrated with the data 
management system permits use of existing hardware 
while allowing future growth to utilize new 

10 equipment at less cost and further, allows for 

incremental expansion as applications and database 
capacities grow. 

Further features and advantages of the 
invention will become more readily apparent from a 

15 consideration of the following detailed description 

set forth with reference to the accompanying 
drawings, which specify and show preferred 
embodiments of the invention, wherein like elements 
are designated by identical references throughout 

20 the drawings; and in which: 

Figure 1 illustrates conceptually an 
existing mainframe -based data delivery system 10 
providing customer's call detail data; 

Figure 2 illustrates the software 

25 architecture component comprising a three- tiered 

structure; 

Figure 3 is a diagrammatic overview of 
the software architecture of the networkMCI 
Interact system; 
30 . Figure 4 is an illustrative example of a 

backplane architecture schematic; 
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Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page; 

Figure 6 is a diagram depicting the 
physical networkMCI Interact system architecture; 

Figure 7 is a block diagram depicting the 
physical architecture of the StarWRS component of 
networkMCI Interact Reporting system; 

Figure 8 illustrates the primary 
components implemented in the StarODS priced 
reporting component 400; 

Figure 9 illustrates the data model 
implemented for accessing information used in 
priced reporting system of nMCI Interact; 

Figure 10(a) illustrates the logical 
Report Manager/DSS application programming 
interface; 

Figure 10(b) illustrates the logical 
DSS/Report Manager application programming 
interface; 

Figures 11(a) -1Kb) illustrate an 
overview of the process performed by the DSS in 
routing a request; 

Figure 12 (a) illustrates an overview of 
the DSS connections enabling guaranteed message 
delivery in the nMCI Interact System; 

Figure 12(b) illustrates the formatter 
process implemented in the DSS server; 

Figures 13 (a) -13(c) illustrate the end- 
to-end process 600 for fulfilling priced report 
request; 
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Figure 14 illustrates a logical message 
format sent from the client browser to the desired 
middle tier server for a particular application; 
and 

Figures 15(a) and 15(b) are schematic 
illustrations showing the message format passed 
between the Dispatcher server and the application 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher server (Figure 15 (b) ) • 

The present invention is one component of 
an integrated suite of customer network management 
and report applications using a Web browser 
paradigm. Known as the networkMCI Interact system 
("nMCI Interact") such an integrated suite of Web- 
based applications provides an invaluable tool for 
enabling customers to manage their 
telecommunication assets, quickly and securely, 
from anywhere in the world. 

The nMCI Interact system architecture is 
basically organized as a set of common components 
comprising the following: 

1) an object-oriented software 
architecture detailing the client and server based 
aspect of nMCI Interact; 

2) a network architecture defining the 
physical network needed to satisfy the security and 
data volume requirements of the networkMCI System; 

3) a data architecture detailing the 
■•' application, back-end or legacy data sources 

available for networkMCI Interact? and 
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4) an infrastructure covering security, 
order entry, fulfillment, billing, self -monitoring, 
metrics and support. 

Each of these common component areas will 
be generally discussed hereinbelow. 

Figure 2 is a diagrammatic illustration 
of the software architecture component in which the 
present invention functions. A first or client 
tier 4 0 of software services are resident on a 
customer work station and provides customer access 
to the enterprise system, having one or more 
downloadable application objects directed to front 
end business logic, one or more backplane service 
objects for managing sessions, one or more 
presentation services objects for the presentation 
of customer options and customer requested data in 
a browser recognizable format and a customer 
supplied browser for presentation of customer 
options and data to the customer and for internet 
communications over the public Internet. 
Additionally applications are directed to front end 
services such as the presentation of data in the 
form of tables and charts, and data processing 
functions such as sorting and summarizing in a 
manner such that multiple programs are combined in 
a unified application suite, A second or middle 
tier 42, is provided having secure web servers and 
back end services to provide applications that 
establish user sessions, govern user authentication 
and their entitlements, and communicate with 
adaptor programs to simplify the interchange of 
data across the network. 

A third or back end tier 45 having 
applications directed to legacy back end services 
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including database storage and retrieval systems 
and one or more database servers for accessing 
system resources from one or more legacy hosts. 

Generally, the customer workstation 
includes client software capable of providing a 
platform -independent , browser -based, consistent 
user interface implementing objects programmed to 
provide a reusable and common GUI abstraction and 
problem- domain abstractions. More specifically, 
the client- tier software is created and distributed 
as a set of Java classes including the applet 
classes to provide an industrial strength, object- 
oriented environment over the Internet, 
Application- specif ic classes are designed to 
support the functionality and server interfaces for 
each application with the functionality delivered 
through the system being of two -types: 1) cross- 
product, for example, inbox and reporting 
functions, and 2) product specific, for example, 
toll free network management or Call Manager 
functions. The system is capable of delivering to 
customers the functionality appropriate to their 

product mix. 

Figure 3 is a diagrammatic overview of 
the software architecture of the networkMCI 
Interact system including: the Customer Browser 
(a.k.a. the Client) 50; the Demilitarized Zone 
(DMZ) 47 comprising a Web Servers cluster 44; the 
MCI Intranet Dispatcher Server 46; and the MCI 
Intranet Application servers 60, and the data 
warehouses, legacy systems, etc. 80. 

A customer workstation 51 employs a Web 
Browser 50 implementing client applications 
responsible for presentation and front- end 
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services. Its functions include providing a user 
interface to various MCI services and supporting 
communications with MCI's Intranet web server 
cluster 44. As illustrated in Figure 3, the client 
tier software is responsible for presentation 
services to the customer and generally includes a 
web browser 50 and additional object-oriented 
programs residing in the client workstation 
platform 51. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific 
application, providing an area of functionality. 
The applications generally are integrated using a 
-backplane" services layer 52 which provides a set 
of services to the application objects which 
provide the front end business logic and manages 
their launch. The networkMCI Interact common set 
of objects provide a set of services to each of the 
applications such as: 1) session management; 2) 
application launch; 3) inter- application 
communications; 4) window navigation among 
applications; 5) log management; and 6) version 

management . 

The primary common object services 

include: graphical user interface (GUI) ; 
communications; printing; user identity, 
authentication, and entitlements; data import and 
export; logging and statistics; error handling; and 
messaging services. 

Figure 4 is a diagrammatic example of a 
backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 52 is 
programmed as a Java applet which can be loaded and 
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launched by the web browser 50, With reference to 
Figure 4, a typical user session starts with a web 
browser 50 creating a backplane 52, after a 
successful logon. The backplane 52, inter alia, 

5 presents a user with an interface for networkMCI 

Interact application management. A typical user 
display provided by the backplane 52 may show a 
number of applications the user is entitled to run, 
each application represented by buttons depicted in 

10 Figure 4 as buttons 58a, b,c selectable by the user. 

As illustrated in Figure 4, upon selection of an 
application, the backplane 52 launches that 
specific application, for example, Service Inquiry 
54a or Alarm Monitor 54b, by creating the 

15 application object. In processing its functions, 

each application in turn, may utilize common object 
services provided by the backplane 52. Figure 4 
shows graphical user interface objects 56a, b 
created and used by a respective application 54a, b 

20 for its own presentation purposes. 

Figure 5 illustrates an example client 
GUI presented to the client/customer as a browser 
web page 71 providing, for example, a suite 7 0 of 
network management reporting applications 

25 including: MCI Traffic Monitor 72; an alarm monitor 

73? a Network Manager 74 and Intelligent Routing 
75. Access to network functionality is also 
provided through Report Requester 76, which 
provides a variety of detailed reports for the 

30 client/customer and a Message Center 77 for 

providing enhancements and functionality to 
traditional e-mail communications. 

As shown in Figures 3 and 4, the browser 
resident GUI of the present invention implements a 
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single object, COBackPlane which keeps track of all 
the client applications, and which has capabilities 
to start, stop, and provide references to any one 
of the client applications. 

The backplane 52 and the client 
applications use a browser 50 such as the Microsoft 
Explorer versions 4.0.1 or higher for an access and 
distribution mechanism. Although the backplane is 
initiated with a browser 14, the client 
applications are generally isolated from the 
browser in that they typically present their user 
interfaces in a separate frame, rather than sitting 
inside a Web page. 

The backplane architecture is implemented 
with several primary classes. These classes 
include COBackPlane, COApp, COAppImpl, COParm. and 
COAppFrame classes. COBackPlane 52 is an 
application backplane which launches the 
applications 54a, 54b, typically implemented as 
COApp. COBackPlane 52 is generally implemented as 
a Java applet and is launched by the Web browser 
50. This backplane applet is responsible for 
launching and closing the COApps. 

When the backplane is implemented as an 
applet, it overrides standard Applet methods 
initO, start (), stopO and run() . In.theinitO 
method, the backplane applet obtains a COUser user 
context object. The COUser object holds 
information such as user profile, applications and 
their entitlements. The user's configuration and 
application entitlements provided in the COUser 
context are used to construct the application 
toolbar and Inbox applications. When an 
application toolbar icon is clicked, a particular 
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COApp is launched by launchAppO method. The 
launched application then may use the backplane for 
inter-application communications, including 
retrieving Inbox data. 

The COBackPlane 52 includes methods for 
providing a reference to a particular COApp, for 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references 
to application objects by name. Once retrieved in 
this manner, the application object's public 
interface may be used directly. 

As shown in Figure 3, the aforesaid 
objects will communicate the data by establishing a 
secure TCP messaging session with one of the DMZ 
networkMCI Interact Web servers 44 via an Internet 
secure communications path 32 established, 
preferably, with a secure sockets SSL version of 
HTTPS. The DMZ networkMCI Interact Web servers 44 
function to decrypt the client message, preferably 
via the SSL implementation, and unwrap the session 
key and verify the users session. After 
establishing that the request has come from a valid 
user and mapping the request to its associated 
session, the DMZ Web servers 44 will re- encrypt the 
request using symmetric encryption and forward it 
over a second socket connection 33 to the dispatch 
server 46 inside the enterprise Intranet. 

A networkMCI Interact session is 
designated by a logon, successful authentication, 
followed by use of server resources, and logoff. 
However, the world-wide web communications protocol 
uses HTTP, a stateless protocol, each HTTP request 
and reply is a separate TCP/IP connection, 
completely independent of all previous or future 
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connections between the same server and client. 
The nMCI Interact system is implemented with a 
secure version of HTTP such as S-HTTP or HTTPS, and 
preferably utilizes the SSL implementation of 
HTTPS. The preferred embodiment uses SSL which 
provides a cipher spec message which provides 
server authentication during a session . The 
preferred embodiment further associates a given 
HTTPS request with a logical session which is 
initiated and tracked by a "cookie jar server" 48 
to generate a "cookie" which is a unique server- 
generated key that is sent to the client along with 
each reply to a HTTPS request. The client holds 
the cookie and returns it to the server as part of 
each subsequent HTTPS request. As desired, either 
the Web servers 44, the cookie jar server 48 or the 
Dispatch Server 46, may maintain the "cookie jar" 
to map these keys to the associated session. A 
separate cookie jar server 48, as illustrated in 
Figure 3 has been found desirable to minimize the 
load on the dispatch server 46 . This form of 
session management also functions as an 
authentication of each HTTPS request, adding an 
additional level of security to the overall 
process . 

As illustrated in Figure 3, after one of 
the DMZ Web servers 44 decrypts and verifies the 
user session, it forwards the message through a 
firewall 55b over a TCP/IP connection 33 to the 
dispatch server 46 on a new TCP socket while the 
original socket 32 from the browser is blocking, 
waiting for a response. The dispatch server 46 
will unwrap an outer protocol layer of the message 
from the DMZ services cluster 44, and will 
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reencrypt the message with symmetric encryption and 
forward the message to an appropriate application 
proxy via a third TCP/IP socket 37. While waiting 
for the proxy response, all three of the sockets 
32, 33, 37 will be blocking on a receive. 
Specifically, once the message is decrypted, the 
wrappers are examined to reveal the user and the 
target middle- tier (Intranet application) service 
for the request. A first- level validation is 
performed, making sure that the user is entitled to 
communicate with the desired service. The user's 
entitlements in this regard are fetched by the 
dispatch server 4 6 from StarOE server 69 at logon 
time and cached. 

If the requestor is authorized to 
communicate with the target service, the message is 
forwarded to the desired service's proxy. Each 
application proxy is an application specific daemon 
which resides on a specific Intranet server, shown 
in Figure 3 as a suite of mid-range servers 60. 
Each Intranet application server of suite 60 is 
generally responsible for providing a specific 
back-end service requested by the client, and, is 
additionally capable of requesting services from 
other Intranet application servers by communicating 
to the specific proxy associated with that other 
application server. Thus, an application server not 
only can offer its browser a client to server 
interface through the proxy, but also may offer all 
its services from its proxy to other application 
servers. In effect, the application servers 
requesting service are acting as clients to the 
application servers providing the service. Such 
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mechanism increases the security of the overall 
system as well as reducing the number of 
interfaces . 

The network architecture of Figure 3 may 
also include a variety of application specific 
proxies having associated Intranet application 
servers including: a StarOE proxy for the StarOE 
application server 69 for handling authentication 
order entry/billing; an Inbox proxy for the Inbox 
application server 61, which functions as a 
container for completed reports, call detail data 
and marketing news messages, a Report Manager Proxy 
capable of communicating with a system- specif ic 
Report Manager server 62 for generating, managing 
and scheduling the transmission of customized 
reports including, for example: call usage analysis 
information provided from the StarODS server 63; 
network traffic analysis/monitor information 
provided from the Traffic view server 64; virtual 
data network alarms and performance reports 
provided by Broadband server 65; trouble tickets 
for switching, transmission and traffic faults 
provided by Service Inquiry server 66; and toll 
free routing information provided by Toll Free 
Network Manager server 67 . 

As partially shown in Figure 3, it is 
understood that each Intranet server of suite 60 
communicates with one or several consolidated 
network databases which include each customer's 
network management information and data. In the 
present invention the Services Inquiry server 36 
includes communication with MCI's Customer Service 
Management legacy platform 80 (a) . Such network 
management and customer network data is 
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additionally accessible by authorized MCI 
management personnel . As shown in Figure 3 , other 
legacy platforms 80(b), 80(c) and 80(d) may also 
communicate individually with the Intranet servers 
for servicing specific transactions initiated at 
the client browser. The illustrated legacy 
platforms 80(a) -(d) are illustrative only and it is 
understood other legacy platforms may be 
interpreted into the network architecture 
illustrated in Figure 3 through an intermediate 
midrange server 60. 

Each of the individual proxies may be 
maintained on the dispatch server 46, the related 
application server, or a separate proxy server 
situated between the dispatch server 46 and the 
midrange server 30. The relevant proxy waits for 
requests from an application client running on the 
customer's workstation 50 and. then services the 
request, either by handling them internally or 
forwarding them to its associated Intranet 
application server 60. The proxies additionally 
receive appropriate responses back from an Intranet 
application server 60. Any data returned from the 
Intranet application server 6 0 is translated back 
to client format, and returned over the internet to 
the client workstation 50 via the Dispatch Server 
46 and at one of the web servers in the DMZ 
Services cluster 44 and a secure sockets 
connection. When the resultant response header and 
trailing application specific data are sent back to 
the client browser from the proxy, the messages 
will cascade all the way back to the browser 14 in 
real time, limited only by the transmission latency 
speed of the network. 
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The networkMCI Interact middle tier 
software includes a communications component 
offering three (3) types of data transport 
mechanisms: 1) Synchronous; 2) Asynchronous; and 3) 
Bulk transfer. Synchronous transaction is used for 
situations in which data will be returned by the 
application server 60 quickly. Thus, a single TCP 
connection will be made and kept open until the 
full response has been retrieved. 

Asynchronous transaction is supported 
generally for situations in which there may be a 
long delay in application server 60 response. 
Specifically, a proxy will accept a request from a 
customer or client 50 via an SSL connection and 
then respond to the client 50 with a unique 
identifier and close the socket connection. The 
client 50 may then poll repeatedly on a periodic 
basis until the response is ready. Each poll will 
occur on a new socket connection to the proxy, and 
the proxy will either respond with the resultant 
data or, respond that the request is still in 
progress. This will reduce the number of resource 
consuming TCP connections open at any time and 
permit a user to close their browser or disconnect 
a modem and return later to check for results. 

Bulk transfer is generally intended for 
large data transfers and are unlimited in size. 
Bulk transfer permits cancellation during a 
transfer and allows the programmer to code 
resumption of a transfer at a later point in time. 

Figure 6 is a diagram depicting the 
physical networkMCI Interact system architecture 
100. As shown in Figure 6, the system is divided 
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into three major architectural divisions including: 
1) the customer workstation 50 which include those 
mechanisms enabling customer connection to the 
Secure web servers 44; 2) a secure network area 47, 
known as the DeMilitarized Zone "DMZ" set aside on 
MCI premises double firewalled between the both the 
public Internet 85 and the MCI Intranet to prevent 
potentially hostile customer attacks; and, 3) the 
MCI Intranet Midrange Servers 60 and Legacy 
Mainframe Systems 80 which comprise the back end 
business logic applications. 

As illustrated in Figure 6, the present 
invention includes a double or complex firewall 
system that creates a "demilitarized zone" (DMZ) 
between two firewalls 55a, 55b. In the preferred 
embodiment, one of the firewalls 55b includes port 
specific filtering routers, which may only connect 
with a designated port address. For example, 
router 84 (firewall 55(a)) may connect only to the 
addresses set for the HydraWeb* (or web servers 44) 
within the DMZ, and router 86 (firewall 55(b)) may 
only connect to the port addresses set for the 
dispatch server 4 6 within the network. In 
addition, the dispatch server 46 connects with an 
authentication server, and through a proxy firewall 
to the application servers. This ensures that even 
if a remote user ID and password are hijacked, the 
only access granted is to one of the web servers 44 
or to intermediate data and privileges authorized 
for that user. Further, the hijacker may not 
directly connect to any enterprise server in the 
enterprise intranet beyond the DMZ, thus ensuring 
internal company system security and integrity. 
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Even with a stolen password, the hijacker may not 
connect to other ports, root directories or 
application servers within the enterprise system, 
and the only servers that may be sabotaged or 

5 controlled by a hacker are the web servers 44. 

The DMZ 47 acts as a double firewall for 
the enterprise intranet because of the double layer 
of port specific filtering rules. Further, the web 
servers 44 located in the DMZ never store or 

10 compute actual customer sensitive data. The web 

servers only transmit the data in a form suitable 
for display by the customer's web browser. Since 
the DMZ web servers do not store customer data, 
there is a much smaller chance of any customer 

15 information being jeopardized in case of a security 

breach. In the preferred embodiment, firewalls or 
routers 84,86 are a combination of circuit gateways 
and filtering gateways or routers using packet 
filtering rules to grant or deny access from a 

20 source address to a destination address. All 

connections from the internal application servers 
are proxied and filtered through the dispatcher 
before reaching the web servers 44. Thus it 
appears to any remote site, that the connection is 

25 really with the DMZ site, and identity of the 

internal server is doubly obscured. This also 
prevents and direct connection between any external 
and any internal network or intranet computer. 

The filtering firewalls 55(a), (b) may 

30 also pass or block specific types of Internet 

protocols. For example, FTP can be enabled only 
for connections to the In -Box server 61, and denied 
for all other destinations. SMTP can also be 
enabled to the In -Box server, but Telnet denied. 

-25- 



SUBSTITUTE SHEET (RULE 26) 



The In-box server 61 is a store and forward server 
for client designated reports, but even in this 
server, the data and meta-data are separated to 
further secure the data, as will be described. 

As previously described, the customer 
access mechanism is a client workstation 51 
employing a Web browser 50 for providing the access 
to the networkMCI Interact system via the public 
Internet 85. When a subscriber connects to the 
networkMCI Interact Web site by entering the 
appropriate URL, a secure TCP/IP communications 
link 32a is established to one of several Web 
servers 44 located inside a first firewall 55a in 
the DM2 47. Preferably at least two web servers 
are provided for redundancy and failover 
capability. In the preferred embodiment of the 
invention, the system employs SSL encryption so 
that communications in both directions between the 
subscriber and the networkMCI Interact system are 
secure . 

In the preferred embodiment, all DMZ 
Secure Web servers 44 are preferably DEC 4100 
systems having Unix or NT-based operating systems 
for running services such as HTTPS , FTP, and Telnet 
over TCP/IP. The web servers may be interconnected 
by a fast Ethernet LAN running at 100 Mbit/sec or 
greater, preferably with the deployment of switches 
within the Ethernet LANs for improved bandwidth 
utilization. One such switching unit included as 
part of the network architecture is a HydraWEB* unit 
82, manufactured by HydraWEB Technologies, Inc., 
which provides the DMZ with a virtual IP address so 
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that subscriber HTTPS requests received over the 
Internet will always be received. The Hydraweb* 
unit 82 implements a load balancing algorithm 
enabling intelligent packet routing and providing 
5 optimal reliability and performance by guaranteeing 

accessibility to the "most available" server. It 
particularly monitors all aspects of web server 
health from CPU usage, to memory utilization, to 
available swap space so that Internet/Intranet 
10 networks can increase their hit rate and reduce Web 

server management costs. In this manner, resource 
utilization is maximized and bandwidth (throughput) 
is improved. It should be understood that a 
redundant Hydraweb® unit may be implemented in a 
15 Hot/Standby configuration with heartbeat messaging 

between the two units (not shown) . Moreover, the 
networkMCI Interact system architecture affords web 
server scaling, both in vertical and horizontal 
directions. Additionally, the architecture is such 
20 that new secure web servers 44 may be easily added 

as customer requirements and usage increases. 

As shown in Figure 6, the most available 
Web server 44 receives subscriber HTTPS requests, 
for example, from the HydraWEB* 82 over a connection 
25 44b and generates the appropriate encrypted 

messages for routing the request to the appropriate 
MCI Intranet midrange web server over connection 
44a, router 86 and connection 44b. Via the 
Hydraweb® unit 82, a TCP/IP connection 3 8 links the 
30 Secure Web server 44 with the MCI Intranet 

Dispatcher server 46. 
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Further as shown in the DMZ 47 is a 
second RTM server 92 having its own connection to 
the public Internet via a TCP/IP connection 88. 
This RTM server provides real-time session 
management for subscribers of the networkMCI 
Interact Real Time Monitoring system. An additional 
TCP/IP connection 88a links the RTM Web server 92 
with the MCI Intranet Dispatcher server 46. As 
further shown in Figure 6, a third router 87 is 
provided for routing encrypted subscriber messages 
from the RTM Web server 92 to the Dispatcher server 
46 inside the second firewall. Although not shown, 
each of the routers 86, 87 may additionally route 
signals through a series of other routers before 
eventually being routed to the nMCI Interact 
Dispatcher server 46. In operation, each of the 
Secure servers 44 function to decrypt the client 
message, preferably via the SSL implementation, and 
unwrap the session key and verify the users session 
from the COUser object authenticated at Logon. 

After establishing that the request has 
come from a valid user and mapping the request to 
its associated session, the Secure Web servers 44 
will re- encrypt the request using symmetric RSA 
encryption and forward it over a second socket 
connection 3 8 to the dispatch server 46 inside the 
enterprise Intranet . 

As described herein, the data 
architecture component of networkMCI Interact 
reporting system is focused on the presentation of 
real time (un-priced) call detail data, such as 
provided by MCI's TrafficView Server 64, and priced 
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call detail data and reports, such as provided by 
MCI's StarODS Server 63 in a variety of user 
selected formats. 

All reporting is provided through a 

5 Report Requestor GUI application interface which 

support spreadsheet, a variety of graph and chart 
types, or both simultaneously. For example, the 
spreadsheet presentation allows for sorting by any 
arbitrary set of columns. The report viewer may 

10 also be launched from the inbox when a report is 

selected. 

A common database may be maintained to 
hold the common configuration data which can be 
used by the GUI applications and by the mid- range 

15 servers. Such common data will include but not be 

limited to: customer security profiles, billing 
hierarchies for each customer, general reference 
data (states, NPA's, Country codes), and customer 
specific pick lists: e.g., ANI's, calling cards, 

20 etc. . An MCI Internet StarOE server will manage 

the data base for the common configuration of data. 

Report management related data is also 
generated which includes 1) report profiles 
defining the types of reports that are available, 

25 fields for the reports, default sort options and 

customization allowed; and 2) report requests 
defining customer specific report requests 
including report type, report name, scheduling 
criteria, and subtotal fields. This type of data 

30 will be resident in an Inbox server database and 

managed by the Inbox server. 

The Infrastructure component of the nMCI 
Reporting system includes means for providing 
secure communications regardless of the data 
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content being communicated. The nMCI Interact 
system security infrastructure includes: 1) 
authentication, including the use of passwords and 
digital certificates; 2) public key encryption, 

5 such as employed by a secure sockets layer (SSL) 

encryption protocol; 3) firewalls, such as 
described above with reference to the network 
architecture component; and 4) non- repudiation 
techniques to guarantee that a message originating 

0 from a source is the actual identified sender. One 

technique employed to combat repudiation includes 
use of an audit trail with electronically signed 
one-way message digests included with each 
transaction. 

5 Another component of the nMCI Interact 

infrastructure includes order entry, which is 
supported by the Order Entry ("StarOE") server. 
The general categories of features to be ordered 
include: 1) Priced Reporting; 2) Real-time 
10 reporting; 3) Priced Call Detail; 4) Real Time Call 

Detail; 5) Broadband SNMP Alarming; 6) Broadband 
Reports; 7) Inbound RTM; 8) Outbound RTM; 9) Toll 
Free Network Manager; and 10) Call Manager. The 
order entry functionality is extended to 
25 additionally support 11) Event Monitor; 12) Service 

Inquiry; 13) Outbound Network Manager; 14) 
Portfolio; and, 15) Client View. 

The Self -monitoring infrastructure 
component for nMCI Interact is the employment of 
30 mid -range servers that support SNMP alerts at the 

hardware level. In addition, all software 
processes generate alerts based on process health, 
connectivity, and availability of resources (e.g., 
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disk usage, CPU utilization, database 
availability) . 

The Metrics infrastructure component for 
nMCI Interact is the employment of means to monitor 
throughput and volumes at the Web servers, 
dispatcher server, application proxies and mid- 
range servers. Metrics monitoring helps in the 
determination of hardware and network growth. 

To provide the areas of functionality 
described above, the client tier 50 is organized 
into a component architecture, with each component 
providing one of the areas of functionality. The 
client -tier software is organized into a 
"component" architecture supporting such 
applications as inbox fetch and inbox management, 
report viewer and report requestor, TFKM, Event 
Monitor, Broadband, Real-Time Monitor, and system 
administration applications. Further functionality 
integrated into the software architecture includes 
applications such as Outbound Network Manager, Call 
Manager, Service Inquiry and Client View. 

The present invention focuses on the 
client and middle- tier service and application 
proxy components that enable customers to request, 
specify, customize, schedule and receive their 
telecommunications network call detail data and 
account information in the form of reports that are 
generated by the various back-end application 
servers. Referred to herein as "StarWRS" , this 
WWW/ Internet Reporting System 2 00, as shown in 
Figure 7, comprises the following components and 
messaging interfaces : 

1) those components associated with the 
Client GUI front end including a report requestor 
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client application 212, a report viewer client 
application 215 and, an Inbox client application 
210 which implement the logical processes 
associated with a "Java Client", i.e., employs Java 

5 applets launched from the backplane (Figure 3) that 

enable the display and creation of reports and 
graphs based on the fields of the displayed 
reports, and, allows selection of different 
reporting criteria and options for a given report; 

10 and, 

2) those middle -tier server components 
enabling the above-mentioned reporting 
functionality including: a Report Manager server 
250, a Report scheduler server 260, and an Inbox 
15 Server 270. Also shown in Figure 7 are the system 

Order Entry client application 280 and a 
corresponding Order Entry Server 285 supporting the 
StarWRS reporting functionality as will be 
described. 

20 Each of these components will now be 

described with greater particularity hereinbelow. 

The Report Manager ("RM") server 250 is 
an application responsible for the synchronization 
of report inventory with the back-end "Fulfilling" 

25 servers 300; retrieval of entitlements, i.e., a 

user's security profiles, and report pick list 
information, i.e., data for user report 
customization options, from the system Order Entry 
server 280; the transmission of report responses or 

30 messages to the Dispatcher server 26 (Figure 7) ; 

the maintenance of the reporting databases; and, 
the management of metadata used for displaying 
reports. In the preferred embodiment, the RM 
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server 250 employs a Unix daemon that passively 
listens fpr connect requests from the GUI client 
applications and other back-end servers and deploys 
the TCP/IP protocol to receive and route requests 
and their responses. Particularly, Unix stream 
sockets using the TCP/IP protocol suite are 
deployed to listen for client connections on a 
well-known port number on the designated host 
machine. Client processes, e.g., report requestor 
212, wishing to submit requests connect to RM 250 
via the dispatcher 26 by providing the port number 
and host name associated with RM 250. Request 
messages received by the RM server are translated 
into a "metadata 11 format and are validated by a 
parser object built into a report manager proxy 
250 1 that services requests that arrive from the 
GUI front -end. If the errors are found in the 
metadata input, the RM 250 returns an error message 
to the requesting client. If the metadata passes 
the validation tests, the request type will be 
determined and data will be retrieved in accordance 
with the metadata request after which a response 
will be sent back to the requesting client. 

As shown in Figure 7, interface sockets 
252 are shown connecting the Dispatcher server 46 
and the RM server 250 and, other socket connections 
254, 256 provide the interface between the RM 250 
and respective middle tier systems 400 and 500. 
For instance, fulfilling system 400 receives 
requests for a customer's priced billing data 
through a publish- and- subscribe Talarian smart 
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socket messaging interface 350 providing guaranteed 
message delivery of messages from the Report 
Manager. It should be understood that the RM 250 
server can manage reporting data for customer 
presentation from other middle- tier and back-end 
legacy systems including, e.g., TrafficView, 
Broadband, Service Inquiry, etc. in order to 
present to a customer these types of network 
management data. 

The report manager server additionally 
utilizes a database 258, such as provided by 
Informix, to provide accounting of metadata and 
user report inventory. Preferably, an SQL 
interface is utilized to access stored procedures 
used in processing requests and tracking customer 
reports. A variety of C++ tools and other tools 
such as Rogue Wave's tools. h++ are additionally 
implemented to perform metadata message parsing 
validation and translation functions. 

The Report Manager server 250 
additionally includes the scheduling information, 
however, a report scheduler server component passes 
report requests to the back-end fulfilling systems 
400, 500 at the scheduled times. 

The Report Scheduler ("RS") server 
component 260 is a perpetually running Unix daemon 
that deploys the TCP/IP protocol to send requests 
to the back-end fulfilling servers 400, 500, and 
receive their responses. More particularly, the RS 
server 260 is a Unix server program designed to 
handle and process report requests to the 
fulfilling servers by deploying Unix stream sockets 
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using the TCP/IP protocol suite, and sending the 
report request to client connections on a 
well-known port number on the designated host 
machine. As shown in Figure 7, interface socket 

5 connections 264, 266 are shown interfacing with 

respective back end servers 400 and 500, In the 
case of priced billing data from a StarODS 
fulfilling server 400, report requests are 
published by the RS server 260 to a pre-defined 

10 subject on the Talarian Server. When handling 

other incoming messages published by back end 
servers using Talarian SmartSockets 4,0, another 
daemon process is provided that uses Talarian C++ 
objects to connect their message queue and extract 

15 all messages for a given subject for storage in a 

database table included in database 263. Each 
message includes the track number of the report 
that was requested from the fulfilling server. 

From the report scheduler interface, the 

20 user may specify the type of reporting, including 

an indication of the scheduling for the report, 
e.g., hourly, daily, weekly or monthly. For priced 
data the user has the option of daily, weekly, or 
monthly., For real-time, or unpriced data, the user 

25 has the option of hourly, daily, weekly or monthly. 

The report scheduler interface additionally enables 
a user to specify a page or E-mail account so that 
a respective page or e-mail message may be sent to 
indicate when a requested report is in the Inbox 

30 server 270. 
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As shown in Figure 7 , the report 
scheduler server 260 interfaces directly with the 
Report Manager server 250 to coordinate report 
request processing. The respective report 
management and scheduling functions could be 
performed in a single server. 

The Inbox Server component 27 0 serves as 
the repository where the completed user report data 
is stored, maintained, and eventually deleted and 
is the source of data that is uploaded to the 
client user via the dispatcher over a secure socket 
connection 272. It is also a Unix program that is 
designed to handle and process user requests 
submitted in metadata format using an Informix 
database. Once report results are received from 
the StarODS 400 and TVS 500 and any other middle 
tier or fulfilling servers, the Inbox server 270 
requests the metadata from the Report Manager 
server 2 50 as indicated by the socket connection 
272 in Figure 7. The metadata is stored in the 
Inbox server database 273 along with the report 
results. Thus, if the metadata is required to be 
changed, it will not interfere with the information 
needed to display the reports contained in the 
Inbox. Additionally, as shown in Figure 7, the 
Inbox server interfaces with the report scheduler 
to coordinate execution and presentation of 
reports . 

The StarOE server 280 is the repository 
of user pick lists and user reporting entitlements 
as shown in database 283. Particularly, it is 
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shown interfacing with the Inbox server 270 and 
report scheduler servers 260. The Report Manager 
does not interface with or include metadata for 
StarOE. It will, however, include information in 
the report metadata that will tell the Report 
Requestor it needs to get information (i.e., Pick 
Lists) from StarOE server 285. Particularly, as 
shown in Appendix A, the StarOE server supports 
pick lists for the selection of priced data based 
on the following list: Date, Time (e.g., provided 
in GMT offset), ID Accounting Code (IDACO/Supp 
code, Access Type, Corp ID, Service Location 
w/Service Location Names, Bill Payer w/Bill Payer 
Names, 8 XX Number, City, State/Province, Numbering 
Plan Area (NPA) , NXX (Exchange code where N=2-9 and 
X=0-9) , and Country Code. 

A common database is maintained to hold 
the common configuration data which can be used by 
the GUI applications and by the mid-range servers. 
Such common data will include but not be limited 
to: customer security profiles, billing hierarchies 
for each customer, general reference data (states, 
NPAs, Country codes) , and customer specific pick 
lists: e.g., ANIs, calling cards, etc.. 

With regard to the front -end client GUI 
components, the above-mentioned Inbox client 
application 210 functions as an interface between 
the client software and the Inbox server 27 0 for 
presenting to the customer the various type of 
reports and messages received at the Inbox 
including all completed reports, call detail, 
alarms, and news. Preferably, the messages for the 
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user in the inbox is sorted by type (e.g., report, 
call detail, alarms) and then by report type, 
report name, date, and time. 

Particularly, the Inbox client 

5 application uses the services of the backplane 

(Figure 3) to launch other applications as needed 
to process report messages. The inbox will also 
use the services of the data export objects to 
provide a save/load feature for inbox messages, 

10 and, is used to provide a user- interface for 

software upgrade/download control. Inbox messages 
are generated by the versioning services of the 
backplane; actual downloads will be accomplished by 
a request through the inbox. 

15 In the preferred embodiment, the inbox 

client receives information on multiple threads to 
allow a high priority message to get through even 
if large download is in progress. Typically, the 
browser is configured to allow more than one 

20 network connection simultaneously, i.e., the 

polling thread on the client uses a separate 
connection to check for new messages, and start a 
new thread on a new connection when a new message 
was detected. In this way, multiple messages may 

25 , be downloaded simultaneously. 

The Report Requester application 212 is a 
GUI Applet enabling user interaction for managing 
reports and particularly includes processes 
supporting: the creation, deletion, and editing of 

30 the user * s reports; the retrieval and display of 

selected reports; the display of selected option 
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data; and the determination of entitlements which 
is the logical process defining what functionality 
a user can perform on StarWRS, In the preferred 
embodiment, a Report request may be executed 
immediately, periodically, or as "one- shots" to be 
performed at a later time. As described herein, 
the report scheduler service maintains a list of 
requested reports for a given user, and forward 
actual report requests to the appropriate middle - 
tier servers at the appropriate time. Additional 
functionality is provided to enable customers to 
manage there inventory, e.g., reschedule, change, 
or cancel (delete) report requests. 

The Report Viewer application 215 is a 
GUI Applet enabling a user "to analyze and display 
the data and reports supplied from the StarODS 
fulfilling system 400. Particularly, the Report 
Manager 250 includes and provides access to the 
metadata which is used to tell the Report Requestor 
what a standard report should look like and the 
"pick- list" options the user has in order for them 
to customize the standard report. It is used to 
tell the Report Viewer client how to display the 
report, what calculations or translations need to 
be performed at the time of display, and what 
further customization options the user has while 
viewing the report. It additionally includes a 
common report view by executing a GUI applet that 
is used for the display and graphing of report data 
and particularly, is provided with spreadsheet 
management functionality that defines what 
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operations can be performed on the spreadsheet 
including the moving of columns, column hiding, 
column and row single and multiple selection, 
import and export of spreadsheet data, and printing 
of spreadsheet, etc. It is also provided with 
report data management functionality by defining 
what operations can be performed on the data 
displayed in a spreadsheet including dynamic 
operations as sorting of report data, sub -totaling 
of report data, etc.. Furthermore, the report 
viewer 215 interprets metadata; and, communicates 
with the Backplane (Figure 4) . The report viewer 
application 215 additionally accepts messages 
telling it to display an image or text that may be 
passed by one of the applications in lieu of report 
data (e.g., Invoice, Broadband report, etc.) 

All reporting is provided through the 
Report Viewer interface which supports spreadsheet, 
a variety of graphic and chart types, or both types 
simultaneously. The spreadsheet presentation 
allows for sorting by any arbitrary set of columns. 
The report viewer 215 is launched from the inbox 
client 210 when a report is selected and may also 
be launched from the inbox when a report is 
selected. 

By associating each set of report data 
which is uploaded from the Inbox server 270 with a 
"metadata" report description object, reports may 
be presented without a report -specific presentation 
code. At one level, metadata descriptions function 
like the catalog in a relational database, 
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describing each row of a result set returned from 
the middle tier as an ordered collection of 
columns. Each column has a data type, a name, and 
a desired display format, etc. Column descriptive 
5 information will be stored in an object, and the 

entire result set will be described by a list of 
these objects, one for each column, to allow for a 
standard viewer to present the result set, with 
labeled columns. Nesting these descriptions within 
10 one another allows for breaks and subtotaling at an 

arbitrary number of levels. The same metadata 
descriptions may be used to provide common data 
export and report printing services. When extended 
to describe aggregation levels of data within 
15 reporting dimensions, it may be used for generic 

rollup/drilldown spreadsheets with * just- in- time" 
data access. 

The metadata data type may include 
geographic or telecommunications- specif ic 
20 information, e.g., states or NPAs. The report 

viewer may detect these data types and provide a 
geographic view as one of the graph/chart types. 

Referring now to Figure 8, there is shown 
the high-level logical approach of the StarODS data 
25 management system 400 integrated with the StarWRS 

component 200 of the nMCI Interact architecture. 
Generally, the data management system 400 of the 
invention, referred to herein" as "StarODS", 
provides customers with priced reporting data 
30 pertaining to telecommunications services. 

Although the description herein pertains to priced 
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billing data, it should be understood that the 
principles described herein could apply to any type 
of reporting data. Through StarWRS web -based 
reporting, the StarODS system provides priced 
reporting data and implements a DataMart approach 
for maintaining the data used for customer 
reporting. StarODS stores and incrementally 
processes customer's priced data included in call 
detail records, and loads this processed data in 
Data Marts. From these data marts customer's 
priced reporting data may be provided to customers 
on a daily basis via the StarWRS reporting system. 

For priced reporting data, report 
categories from which a variety of reports can be 
generated include: a) Financial category - for 
providing priced, data reports relating to longest 
calls, most expensive calls, Off Peak Calls, 
payphone report, usage summary, calling card 
summary, and area code summary for Toll Free, VNET, 
Vision, and CVNS customers; b) Marketing category - 
for providing priced data reports relating to 
country code summary, state summary, frequent 
numbers, frequent area code summary, frequent 
state, and frequent cities; c) Telecommunications 
category - for providing priced data reports 
relating to call duration summary, IDACC/Supp Code 
Summary and Call Access Summary for Toll Free, 
VNET, Vision, CVNS customers; d) Call Center report 
category- for providing priced data reports 
relating to most active toll free numbers, Hourly 
Distribution, Day of Week Distributions, state 
summary, and country code summary for their Toll 
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Free, VNET, Vision, CVNS customers; e) Monitor 
Usage - for providing priced data reports relating 
to longest calls, most expensive calls, most active 
calling card and most active toll free numbers for 
their Toll Free, VNET, Vision, CVNS customers; f) 
Analyze Traffic - area code summary, country code 
summary, state summary, range summary, city 
summary, frequent numbers, payphone report, usage 
summary, calling card summary, IDACC/Supp Code 
Summary, Day of Week Distributions, Hourly 
Distribution, Call Access Summary and review calls; 
and, a g) Check Calling Frequencies category - for 
reporting on frequent numbers, frequent area code, 
frequent country codes, frequent state and frequent 
cities. 

Figure 8 illustrates the primary 
components implemented in the StarODS priced 
reporting data management component 400. As shown 
in Figure 8, a first traffic feed 405 provides raw 
call detail records from external network switches, 
translates and sorts the data into billable records 
for input into two systems: a Commercial Billing 
system ("NCBS") mainframe server process 410 for 
pricing the records at tariff for customers 
subscribing to, e.g., MCI's VNET and Vision 
telecommunications products; and, a toll-free 
billing server process 42 0 for pricing the records 
at tariff for customers subscribing to toll-free 
telecommunications products. A common data gateway 
component 4 30 including a mainframe extract process 
43 5 and a data harvesting process 440 receives 
these inputs on both a daily and monthly basis for 
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processing. Particularly, the mainframe extract 
process 435 creates a selection table including all 
subscribing customers, compresses files for 
transmissions and extracts priced reporting records 
from the runstreams. The harvesting process 44 0 is 
responsible for performing data validations, 
filtering, data translations, data grouping, data 
routing, and data logging functions. According to 
a dimension table based on data within selected 
BDRs , the harvesting process applies business rules 
to the data, cleanses the data, transforms the 
data, creates load files for DataMarts and 
compresses files for storage in the DataMarts. The 
harvesting component 440 may additionally perform 
an aggregation function for supporting long term 
storage and rapid access of data for customer 
reporting, and performs trigger actions/events 
based on predefined criteria. 

Additionally, as shown in the Figure 8, 
other external systems and applications may 
interface with the common data gateway component 
430 including: Cyclone Billing system 422a and 
Concert Virtual Network Services 422b which provide 
additional billing detail records; and, a calling 
area database 425 which provides geographical 
reference information, i.e., identify city, state 
and country information. 

After the data has been processed in the 
Harvesting component 440 it is input to an 
operational data store component ("ODS") 450 that 
stores the billing detail records and dimension 
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tables as a data model. This ODS layer 450 is 
comprised of all data harvested from all 
applications in the data harvesting layer 430, and 
feeds report -supporting DataMarts 470 in a manner 

5 which supports customized data access. The 

Datamarts may be engineered to pre-process data, 
create aggregates, and otherwise perform 
transformations on the data prior to DataMart 
loading 465 in order to implement a defined data 

10 model, e.g., star schema key structures, fact and 

dimension tables depicted as block 460. In the 
preferred embodiment, as shown in Figure 8, the 
Operational Data Store 450 includes multiple 
datamarts 47 0 each for storing and retrieving daily 

15 and monthly priced data on a periodic basis. It 

primarily is responsible for hosting highly current 
data, typically at least 72 hours old. In 
accordance with customer -reporting needs, data 
marts 470 are partitioned in accordance with 

20 partitioning schemes which, in the invention, is 

based on customer- ID. Particularly, each DataMart 
is engineered for servicing specific customers or 
specific product sets, as well as engineered for 
the specific requirements of the customer/product 

25 such as high insert activity, heavy reporting 

requirements, etc. As data is volatile and 
changing and may not produce consistent results for 
the same query launched at multiple times, ODS is 
engineered for high performance through appropriate 

30 storage technologies and parallel processing. 

Although not shown, a common data warehouse is 
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provided in this ODS layer that is responsible for 
performing storage, retrieval and archiving of 
data, typically of relaxed currency (e.g., more 
than 24 hours) and is targeted at trend analysis 
5 and detection. In the preferred embodiment, the 

datamarts utilize an Informix database in a star 
topology. 

Particularly, as illustrated in Figure 9, 
the data model 459 is one component comprising the 

10 priced reporting data store. In the preferred 

embodiment, the data model of StarODS is a 
dimensional or "star schema" model, including a 
central fact table multiply joined to a number of 
attendant tables known as dimensions. The 

15 relationships between the fact table and the 

dimensional tables are either enforced through 
keys, which may be generated, or as lookup codes. 
As shown in Figure 9, the central fact table 461, 

referred to herein as "Perspective Base," provides 

« 

20 access to a collection of attributes or facts 

concerning a call. The dimensional tables include 
the following: an Access Termination table 462 
comprising data indicating whether a call was 
charged to recipient (inbound) or originator 

25 (outbound) ; an Access Type table 464 comprising 

data indicating the type of access (for outbound 
calls) or egress (for inbound calls) 
characteristics of a call; a Billing Corp table 466 
comprising data indicating the hierarchical status 

30 of a customer for the purposes of billing charges 

for products and features; a Toll Free Number table 
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468 comprising data indicating any dialed number in 
which the three digits following the country code 
(1 for USA) is currently either 800 or 888; a 
Product Type table 469 comprising data indicating 

5 the product for which- services are bundled for the 

purpose of invoicing; a GMT table 471 comprising 
date and time data adjusted to the Greenwich Mean 
Time Zone; a LST table 473 comprising date and time 
data adjusted to the local MCI switch which 

10 permitted access to the MCI network; an Orig_Geo 

table 476 comprising data indicating the geographic 
characteristics of a call's origination; a Term_Geo 
table 477 comprising data indicating the geographic 
characteristics of a call's termination; a Report 

15 Geo table 47 8 comprising data indicating the 

geographic characteristics of a call's origination 
or termination; an Idacc table 479 comprising data 
indicating a customer's defined id and/or 
accounting code; a Data Stream table 481 comprising 

20 data relating to the line speed characteristics of 

a data (non- voice) call; a Pay Phone table 482 
comprising data denoting calls originating from a 
payphone; a Usage table 4 83 comprising data 
indicating the geographic attributes of a call 

25 which affect Tariff rates; an EVS Product table 484 

comprising data representing Enhanced Voice 
Services products; a Directory Assistance table 486 
comprising data indicating those calls requesting 
Directory assistance; a Range table 487 comprising 

30 data indicating distance bands a call may fall 

into; an NCR table 4 88 indicating Network Call 
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Redirect calls; a Cell Phone table 489 comprising 
cellular call characteristics data; a VOS table 491 
indicating Voice Operator Services calls; a 
Conference Call table 492 having data pertaining to 
characteristics of conference calls; a Cross Corp 
table 493 comprising data indicating inbound cross 
corporate routing of calls? a Currency table 494 
indicating unit of currency for call prices; a card 
table 496 comprising data for billing calls to a 
location that may not be the one which originated 
the call an NCT table 497 comprising data 
representing Network Call Transfers; an Amount 
Range table 498 indicating call usage ranges based 
upon amounts; and, a Duration .Range table 499 
indicating call usage durations based on amounts. 
This star schema model is optimized for decision 
support and the retrieval of large amounts of data. 
Appendix H provides the data attributes of each of 
these dimension tables. As known, in the 
dimensional model, the grain of data stored in the 
fact table determines what level of data can be 
drilled down into. It should be understood that 
the grain of the data stored in the Perspective 
Base table is at the singular call level. 

As described herein, from the data 
included in these data marts, one-time or recurring 
priced data reports are available for reporting 
through the NMCI Interact StarWRS reporting system 
200. 

Additionally, referring back to Figure 8 
there is provided a Decision Support Server ("DSS") 

-48- 



SUBSTITUTE SHEET (RULE 26) 



reporting engine component 47 5 that performs the 
following functions: 1) receives various customer 
report requests from the StarWRS GUI Report 
Requestor component and accordingly generates 
database queries; 2) routes the query to the 
appropriate data marts 470, data warehouse or 
operational data store; and, 3) responds to the 
requestor with a formatted result set. The DSS 
server 475 may also perform cost estimation, agent 
scheduling, workflow broadcasting interface, and 
transaction logging functions. In the preferred 
embodiment, the DSS 475 is a cluster of DEC 
(Digital Equipment Corp.) UNIX 8400 servers running 
Information Advantage® software accessing an 
Informix database, e.g., Informix Dynamic Server 
V.7.3. database product, distributed across 
multiple Data Marts. 

In accordance with the invention, the 
primary function of the DSS 475 is to generate 
priced billing report data in accordance with the 
customer's request which is received from the 
StarWRS reporting component as a metadata message. 
To accomplish this, the DSS interfaces with two 
StarWRS systems: Report Manager 250, and Inbox 270, 
as shown in Figure 8. The Report Manager/Scheduler 
formats the customer's request in accordance with a 
defined set of rules and sends a metadata request 
message to the DSS. The DSS 475 reads the 
customer's metadata descriptions of the type of 
priced data report requested by a customer, 
translates the metadata into database queries, and 
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implements commercial off-the-shelf ("COTS") tools 
such as Information Advantage's Decision Suite™ to 
generate SQL queries, and run the queries against 
the data in the DataMarts. Afterwards, the query 
5 results are formatted by a formatter process into a 

form readable by StarWRS report viewing components, 
and the completed reports are transmitted to the 
directory of the customer's Inbox, e.g., via FTP. 

In the preferred embodiment, a publish- 
10 and -subscribe communications tool such as Talarian 

SmartSockets™ messaging middleware is used to 
coordinate report requests transmitted from the 
StarWRS report Manager to DSS, and report 
completion notification from DSS to the StarWRS 
15 Report Manager. The Report Manager formats the 

customer's request in accordance to a defined set 
of rules and sends the request to the DSS as a 
Talarian message with the Report Manager 250 
maintaining the Talarian Sender program, and the 
20 Decision Support Server 475 maintaining the 

Talarian Receiver program. Messages are sent with 
guaranteed message delivery ( "GMD" ) , thus assuring 
all request data sent by RM is received by the DSS. 
As known, Talarian messaging middleware defines a 
25 message as types and subjects. A message type is a 

structure that defines the format of the message. 
Message subjects are subsets of message types and 
describe messages by which Talarian receivers can 
subscribe. Conversely, message subjects describe 
30 messages by which Talarian senders publish. 
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As depicted in greater detail in Figure 
10(a), a Report Manager/DSS application programming 
interface "API" 4 80 is provided whereby the RM 
server 250 publishes the message to the Decision 
Support Server in response to its receipt of a 
report request. Subsequently, the DSS 47 5 returns 
a "Message Received" message. When the DSS has 
processed the request, it publishes the message to 
the RM 250 with the name and location of the report 
file or an error message to the Report Manager, via 
an "NRL" metadata message as described herein. 

Figure 10(b) illustrates an DSS/Report 
Manager application programming interface "API" 
485. In the preferred embodiment, all return 
messages are persistent. Thus, as shown in Figure 
8 the DSS incorporates a Talarian message queue 490 
operating on a First-In-First-Out (FIFO) basis. If 
the DSS is unable to establish the connection with 
Talarian, or there is an error in transmission, the 
DSS queues all messages, and continues to retry 
until a successful send is executed. 

Similarly, a DSS/Inbox API is provided to 
manage FTP file transmissions including: error 
handling, retry logic, and the ability to maintain 
the file name and location of where report files 
are stored. Particularly, the DSS/Inbox API sends 
the report file to the inbox (Figure 8) . If the 
DSS has generated an error condition, and the 
report is unable to be generated, an error message 
will be sent to the inbox in place of the report 
file. In either case, a return message will be 

-51- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



delivered to the DSS/Report Manager API 485 
indicating a successful or unsuccessful generation 
and transmission of the report file. 

More particularly, as shown in Figure 
5 12(a), an RTServer process 377 is provided for 

maintaining connections, ensuring guaranteed 
message delivery, and tracking the success of all 
messaging operations. As the Report Manager 
interfaces with multiple systems, the RTServer 377 
10 processes are located in the RM. The DSS is 

provided with RTClient processes 377a, b that 
provides the API to RTServer: one RTClient 377a for 
providing the API to Report Manager for receiving 
messages; and, a second RTClient 377b for providing 
15 the API for the NRL. However, it should be 

understood that other ODS boxes can have one 
RTClient. The RM and Arbitrators 360a, b use the 
GMD feature of Talarian to deliver messages, 
RM/Inbox communication is not affected by outages 
20 of ODS server as the arbitrator and ODS 

communication is independent of RM/Inbox 
communication . 

In the preferred embodiment, the DSS 
architecture is transparent to the Report Manager 
25 which publishes Talarian messages to which the DSS 

will subscribe. In addition to the tokenized 
character string request message which specifies 
report type, filters, and any customer request - 
specific information, RM server provides additional 
30 fields as part of the Talarian request message 

including: a Corp_ID, Priority, and RequestlD. 
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Corp_ID allows the DSS to route the request to the 
appropriate data store without having to invoke a 
parser. Data are partitioned on Corp_ID in the ODS 
database warehouse. Request_id is used to send 
5 back an ARDA failure message, in the event of an 

invalid message. The Priority field allows DSS to 
pickup the next high priority request from a queue 
of non- processed requests, without invoking the 
parser. 

10 Figure 11(b) illustrates the 

implementation of the COTS Information Advantage® 
Interface Object ("IAIO" ) 372, which is a process 
running in the DSS 475 for performing the following 
functions: 1) publishes and subscribes Talarian 

15 messages to Report Scheduler; 2) parses the request 

metadata ARD (Add Report Definition) message; 3) 
publishes an ARDA (Add Report Definition 
Acknowledgment) ; 4) populates a request table 390 
with total, sub- total and sort information 

20 according to the received report request; 5) 

transforms the ARD tokens from the metadata request 
into an overlay file 392 which is a text file that 
is submitted to IA's Decision Suite™ process to 
generate the corresponding SQLs; 6) updates a 

25 Request Status table 391 with appropriate status, 

e.g., process complete, failed, in progress, etc.; 
and, 7) if a failure occurs, it updates an error 
log (not shown) . 

More particularly, in view of Figure 

30 11(b), ARD metadata request messages are received 

into the ODS system via arbitrator processes 360a, b 
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which are responsible for routing the request 
message to the appropriate ODS database according 
to a Corp / OD S . mapping table 365. Report Manager 
publishes a single message subject "Arbitrator" 
5 having the above-mentioned request, Corp_ID, and 

Priority field information. Report Manager uses a 
round robin message delivery mechanism complemented 
by Talarian' s GMD to publish messages to the 
subject Arbitrator 360a, b. The arbitrator extracts 

10 the Corp_ID field from the message and maps the 

Corp_ID to corresponding ODS DataMart in the table 
365 it maintains. The arbitrator then republishes 
the message with the 0DS#. As shown in the Figure 
11(b), a second arbitrator process 360b is provided 

15 to assure fail -over capabilities. 

In Figures 11(a) and 11(b), a Talarian 
receiver, referred to herein as a Talarian 
Interface Object ("TIO") 370, is a process that 
receives the Talarian message, manages the GMD 

20 functionality, and posts updates to the request 

table 390 and request status table 391. As shown 
in Figure 11. (b) , the TIO receivers 370 subscribe to 
a subject "ODS#." The receiver inserts the message 
received from the arbitrator into the request table 

25 390 and request status table 391 along with the 

priority, timestamp and status fields. The request 
status table resides on the ODS database and the 
messages are stored in the queue to provide 
queuing, log and tolerance from the failures. To 

30 determine the pending messages to be processed, 

^ status field and history_stat flags are used. 
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Appendix "I" illustrates the contents of the ODS 
Request table 390 and Request Status tables 391, 
which are part of the ODS database. 

In the preferred embodiment, the tables 

5 provided in Appendix I include: an 

"informix" .request table 390 (Figure 11(a)) which 
is the table maintained for the purpose of holding 
specific report request information from the 
received ARD message, and, an "inf ormix" . req_status 

10 for holding status of DSS processes for the current 

request. 

Thus, for the example ARD message 
provided in Appendix I, the request table 390 will 
be populated to include: a "requested, " which is 

15 the unique identifier for the request; a 

"msg_desc," representing a copy of the ARD message; 
"unique_fname, " which is the unique name assigned 
to each request to enable tracking of individual 
report requests and is additionally assigned to the 

20 report returned to the report manager; a 

"report_dir" indicating the location of the report 
that Decision Suite™ generates (which may be a tab 
delimited report file); "f ormat__dir" indicating the 
location where the report formatter generates 

25 (comma delimited file); "inbox^dir" indicating the 

location on the Inbox (Report Manager) where the 
report is sent; "inbox__f size" indicating the size 
of the file; "entpid, " indicating the Enterprise id 
which may consist of one or more corporate id's; 

30 "userid" which is an identifier assigned to each 

user of the system; "stdrptid"which identifies each 
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report and is similar to column id's but on the 
report level; "userptid" which is the user- assigned 
identifier for a report request; "compress" having 
possible values ' 1' = yes, '2' = no indicating if a 
report is to be compressed, e.g., using a standard 
.zip routine; "threshold" defining the number of 
lines that shall appear on the report; "totalmode" 
which defines how the report shall be totaled, 
subtotaled as indicated by possible values 1 0' = No 
total, No subtotal; '1' = Only Subtotal; '2' = Only 
Total; '3' = Total and Subtotal; "nrl_totals" 
indicating the formatter to total the columns 
specified in the "*.hdr" file. These columns are 
numeric and have a subtotal flag = 'y' in a column 
id table; "forma t_columns" which define derived 
columns on which percentages are to be calculated; 
"error_code" for indicating parser failure or 
system failure. If it's a parser failure 
condition, the code is returned to Report Manager; 
"error_desc" indicating the error description; and, 
"rpmgr_columns" which are the columns sent to the 
DSS by Report Manager. The formatter checks this 
list against the list in the .hdr file. 

Similarly, the Request_Status table 391 
provided in Appendix I is populated to include the 
status of the different processes including: 
"Request_Id, " i.e., the unique identifier for the 
request, "Priority," e.g., having a value of "1," 
for example, meaning adhoc; a "timestamp" which is 
the Informix Date Time that will be used when two 
or more messages have same priority; and "Status" 

-56- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



which is a char message including the following 
status fields: "new_message" indicating that a new 
message has arrived, yet to be processed; "in__ IAIO" 
status indicating that the message is being 

5 processed by interface process IAIO; 

"parser_f ailed" status indicating an Invalid 
message from RM. NRL process sends a ARDA error 
message; "parser_success" status indicating that 
the message from RM is a valid message. NRL process 

10 would send a ARDA message to RM; "IAIO__complete" 

status indicating that the report has been 
generated and directory and file name fields are 
modified. Formatter can pick up this message; 
*IAI0_f ailed" status indicating that IA has failed 

15 to generate a report, i.e., an error has occurred 

generating a report; "in_f ormatter" status 
indicating that the formatter is converting the 
text file generated by IA to a comma delimited 
format. The formatter may also, if required, does 

20 the percent (%) calculations, e.g., subtotals etc.; 

"f ormat_success" status indicating that the 
formatter successfully completed translation of the 
file. It also populates the inbox file name, inbox 
file directory, nrl total (optional) fields in the 

25 table; "forma t_f ailed" status indicating that the 

formatter failed to translate the text file 
generated by IA; "in_f tp" . status indicating that 
the ftp process is currently sending the file to 
inbox; "f tp__success" status indicating that the 

30 file generated by formatter is ftp'd to inbox; 

"ftp_failed" status indicating that the formatted 
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file could not be ftped to inbox; ''in_iJRL'' status 
indicating that the NRL process is trying to send 
either ARDA message or NRL message to RM; 
"NRL_sent" status and "ARDA- sent" status indicating 
that the respective NRL or ARDA message has been 
sent to RM. Each DSS process updates the request 
status table as it processes. 

A further "history_stat" field may be 
provided in the request_status table 391 having a 
value, e.g., ' A' (Active) indicating that the 
record needs to be processed, or, indicating 
'H' (History) , when the record is no longer active 
and needs to be archived in a separate database set 
up for archival purposes (not shown) . 

As further shown in Appendix I, there are 
two more tables that are defined for DSS sorting 
and formatting processes: a Column ID Table, and a 
Translation table which are tables configured for 
the formatter process, as will be described. 

As further shown in Figure 11(b), in 
operation, each Information Advantage® Interface 
Object ("IAIO") 372a,b,..n reads the status table 
391 for new entries. When a new entry is posted, 
it invokes a parser process 393, and invokes the 
Information Advantage® SQL generator engine which 
retrieves the requested data from the database, and 
updates the status table 391. 

Particularly, the Decision Suite™ tool 
receives the overlay file (Figure 11(a)) and 
performs the following functions: 1) generates SQL; 
2) submits the SQL to the appropriate datamart (ODS 
database); 3) generates a Report file with a *.txt 
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extension; 4) updates Request Status table 391 with 
appropriate status; and, 5) if a failure occurs, 
updates the error log. Following generation of the 
*txt file, a sort process is invoked to perform the 
following functions: 1) reads the Request table 390 
for column (s) on which to sort the Report; 2) reads 
the *.txt file; 3) sorts the *.txt file and 
generates two files: i. a file with a *.hdr 
extension which file contains the header 
information, consisting only of only column id's, 
and, ii. a file with a * .data extension which file 
contains sorted data provided in the * . txt file and 
is the body of the Report; 4) it further updates 
the request status table with a 'success' or 
'failure' code; and, 5) if a failure occurs, 
updates the error log. 

As further shown in Figure 1Kb), 
continuously running FTP, NRL and ARDA processes 
are provided to take appropriate actions in 
accordance with the request status table entries. 
For example, an FTP process 378 performs the 
following functions: 1) reads the status table 391 
for entries ready to be sent to the Inbox and FTP'S 
the .csv or .txt to the inbox 270; 2) Determines 
success or failure of file transfer; 3) Updates the 
Request Status table 391; and, if a failure occurs, 
updates an error log. 

The NRL (Notification of Report Location) 
process 382 performs the following functions: 1) 
reads the Request Status table 391 for any success 
status or failure of any process; 2) Invokes a 
receiver process with appropriate status and file 
location populated in the NRL; and, 3) If failure 
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occurs, updates the error log. Particularly, 
should an error occur in any of the DSS processes, 
an error log is updated. Error log directories may 
be delineated , by process and day of week. Each new 
error generated by the same process in the same day 
appends the log with the new message. In either 
event, the NRL process returns the NRL message to 
Report manager indicating the status and location 
of any generated files. 

As further shown in Figure 11(b), an ARDA 
process 383 reads the status table 391 for parser 
failures. Should the parser fail due to 
insufficient or missing data, ARDA process will 
return an ARDA message to the Report Manager with 
the appropriate error code. In particular, the 
types of conditions that result in error messages 
being sent to the report manager and/or local log 
include: i) when the request message received from 
the Report Manager can not be parsed due to bad 
data or invalid format; ii) when the SQL can not be 
generated due to invalid request format or 
parameters; iii) system or process failure; iv) 
cannot query database due to a database failure; 
etc. 

For Priced Reporting, the StarWRS report 
requestor functionality is invoked. Particularly, 
the end -to -end process 600 from a priced report 
request to report delivery is shown in Figure 13(a) 
- 13(c). Specifically, a user first establishes 
communication with the DMZ Web server 44 and logs 
on to the nMCI Interact system by entering the 
user's name and password onto a logon dialog box. 
Then, an application running on the backplane 
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directs a "Validate User Message" common object to 
the StarOE server 280 via the web server and 
dispatcher servers (Figure 3) to direct the StarOE 
server 280 to perform security validation and 

5 authenticate the user ID and password. It is 

understood that all communication to the StarOE 
server is via TCP/IP with a Unix process listening 
on a known TCP port. The StarOE server acts as a 
proxy when messages are sent from the Dispatcher 

10 server 46 and supports synchronous transactions. 

All data and security information is accessed by 
direct queries to a StarOE server database 2 83, 
such as provided by Informix. Once a user is 
logged on, the Web Server 44 (Figures 3 and 7) 

15 requests a current list of authorized applications 

from the StarOE server 285. Particularly, a "Get 
User Application Request" message is communicated 
to the StarOE server via the backplane from the 
report requestor which queries the Informix 

20 database to obtain a list of authorized 

applications, i.e., services, for the user and 
which determines which buttons on the home page are 
active, thus controlling their access to products. 
This information is downloaded by a GUI applet that 

25 is executed via the Backplane (Figure 4) and 

incorporated into the home page that is presented 
to the user. An exemplary home page screen display 
80 is shown in Figure 5 which provides a list of 
icons 7 0 representing the possible options 

30 available to the user according to that customer's 

entitlements. 

The Report Requestor first asks for 
common objects for a user's default timezone, 
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language and currency. The Report Requestor 
objects are invoked to retrieve from StarOE the 
various customer entitlements relating to security, 
geographical hierarchy, billing hierarchy, and 
paging and e-mail notification. 

In response to selection of the Report 
Requestor icon, a display is generated to present 
the reporting options to a user in accordance with 
that user's entitlements as previously determined. 
It should be understood that in the preferred 
embodiment, the icons for applications the user has 
security access to are shown bolded. Thus, for a 
customer subscribing to nMCI Interact Priced 
Reporting, a Priced Reporting icon is automatically 
enabled when the home page appears. 

Thus, upon selection of a Report 
Requestor icon 7 6 from the home page screen display 
80 of Figure 5, a StarWRS report requestor web page 
is presented to the customer. The backplane object 
allows the user access to the Report Requestor 
front end if the user is so authorized, and a 
client priced reporting application is downloaded 
to the customer who is presented with the Priced 
reporting dialog screen (not shown), as indicated 
at step 602 in Figure 13(a). It is from this 
screen that the user is presented with priced 
reporting options to view/retrieve completed 
reports via the StarWRS Inbox, or create a new 
report or, modify an existing Priced call detail 
data report. 

Particularly, from the Priced reporting 
dialog screen, the user is enabled to edit an 
existing report maintained in the report manager 
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inventory, generate a new report, copy an existing 
report, or delete an existing report. For example, 
as indicated at step 605 (Figure 13 (a) ) , a user may 
initiate retrieval of the user report list 
containing existing user reports from the RM 
inventory, which process entails invoking the 
Report Requestor to initiate generation of a 
metadata request to download the report inventory 
from RM as indicated at step 610. The Report 
inventory for the specific user is loaded and 
displayed for the user on the user report request 
display screen, enabling the user to select a 
report, as indicated at step 612. Then, at step 
615, the selected report is retrieved from StarWRS 
Report Manager and displayed for the customer. 

Then, as indicated at steps 618 and 620, 
the customer may enter the desired reporting 
options and reporting criteria including; 1) the 
report product including toll-free, MCI Vision, and 
MCI Vnet options; 2) the report category which 
includes options for: analyzing traffic, call 
center, call detail, checking calling frequencies, 
financial, marketing, monitoring usage, and 
telecommunications categories for toll-free, Vnet 
and Vision customers; 3) the report type which 
includes priced call detail data or traffic data 
options; and 4) a report direction and which 
includes inbound, outbound, or both directions. 
Additionally, the user may select the report format 
associated with a reporting category. 

Whether creating a new report or editing an 
existing report, the user is enabled to select 
customization options from successive dialog 
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screens (not shown) that are presented to the user 
showing all the report customization categories for 
building a new report and/or editing an existing 
report. From this screen and related report 

5 building dialog boxes, all of the initial values 

for retrieving the MetaData, customization options 
and GUI builder options from the report manager 
server 250 necessary to build (edit) a report are 
provided in accordance with the user's 

10 entitlements. A user may provide the following 

customization and report builder options: general 
customization options; layout customization 
options; access customization options; hierarchy 
customization options; geographic customization 

15 options; and, notification customization options. 

In performing the report request process, 
as shown in Figure 7, the Report Requestor client 
application 212 gains access to the Metadata stored 
at the Report Manager server 250 through messaging, 

20 as indicated at step 625. Particularly, as 

hereinafter described, a message generated by the 
Report Requestor in accordance with the user 
request is first received by the report manager 
proxy 250 In the preferred embodiment, the 

25 report manager proxy comprises a set of tools in 

the form of reusable objects, preferably written in 
C++ code, or the like. For example, a parser object 
tool is employed to decompose the Metadata messages 
sent by the report requestor 212 to validate the 

30 message. If errors are found in the Metadata 

input, the RM will return. an error message to the 
requesting client. If the Metadata passes the 
validation tests, the request type is then 
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determined and the appropriate service will be 
invoked after which a standard response is sent 
back to the requesting client or and/or fulfilling 
server . 

5 The Report Manager 250 implements stored 

procedures to translate the message, perform the 
request, and send the information back to the 
Report Requestor 212 which uses the metadata to 
determine what a standard report should look like, 
10 the customization options the user has, and the 

types of screens that should be used for the 
various options (i.e., single selection, multiple 
selections, etc.). 

It is understood that the selection of available 
15 standard template reports is based on the user's 

entitlements . 

The following list provides the types of 
requests that may be initiated by the Report 
Requestor 212 and the responses performed by the 

20 Report Manager 250: 1) Get/Send report template 

list (GRTL/SRTL) - which request retrieves the list 
of all standard report templates for all products 
and is used only to obtain general report 
information, e.g., report title, description, etc.; 

25 2) Get/Send report template detail (GRTD/SRTD) - 

which request retrieves the details of a specific 
standard report template; 3) Get/Send user report 
list (GURL/SURL) - which request retrieves the list 
of all user reports for the report format selected 

30 from a user report table and is used only as a 

request for general report information, e.g., 
report title, status, etc.; 4) Get/Send user report 
detail (GURD/SURD) - which request retrieves the 
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10 



15 



20 



25 



details of a specific user's report; 5) Add report 
definition/Acknowledgment (ARD/ARDA) - which 
requests addition of a user -created report to a 
user report table. If the report is a scheduled 
report, this request is also communicated to the 
fulfilling server at the time the report is due; 6) 
Delete report definition/Acknowledgment (DRD/DRDA) - 
which request deletes a user- created report from 
the user table; 7) Copy, report 

definition/Acknowledgment (CRD/CRDA) - which request 
creates a duplication of the report the user is 
editing (other than the report title) and creates a 
new report ID for it; 8) Update Reporting 
Schedule/Acknowledgment (URS/URSA) - which request 
updates the scheduling information on a report 
without having to send a Delete and Add request; 
and, 9) Get Pick List /Acknowledgment (GPL/GPLA) - 
which request enables the Report Requestor 212 to 
get a pick list provided by StarOE server. 

In a preferred embodiment, as shown in 
Table 1, the interface message sent to the RM 
server 250 from the report requestor via the 
Dispatcher server 46 comprises a three to four 
character message acronym followed by request 
specific parameters. 



30 



Parameter 
Name 


Parameter 
Type 


Required 


Acceptable 
value 


Request 


3 or 4 
Characters 


Yes 


Msg acronym 


Data 

parms- 


Characters 


No 





Table 1 
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Table 2 illustrates the interface message 
format returned by the RM server 250. 



Parameter 
Name 


Parameter 
Type 


Required 

Yes 


Acceptable 
value 

Msa acronym 


Response 
Error Code 


char (4) 
Char (4) 


Yes 


0 = OK or 
error 


Data 

parms- 


Char # 

. 


NO 





Table 2 

As shown in Table 2, the response message to 
be returned in Metadata format preferably includes a 
four character message acronym followed by an error 
code. A successful request (or a request 
acknowledgment) generates a response with an error code 
of "0". Additional data specific to the response 
follows this error code. If any server receives a 
message which is not known, the response message will 
echo the message acronym back along with an appropriate 
error code. 

Appendix A provides a series of tables 
containing the content for each metadata message, 
request that can be sent by the report requestor 212 
for each of the enumerated user requests, in addition 
to the content of the corresponding metadata message 
responses by the RM server 250. As an example, when a 
user requests a list of all standard report templates 
that can be created for a specified product, category, 
and product type, e.g., toll free unpriced data, an 
example metadata format is as follows: 
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GRTL<PRODUCT=V, DATATYPE=R, DATACAT=P , IO=0> 

where GRTL is the message name, the PRODUCT indicates 
the product type, e.g., V=Vnet, C=CVNS, S=Vision, T= 
5 toll free, F= Traffic view, etc. DATATYPE indicates the 

data type, e.g. R=reports, D=call detail, etc., and 
DATACAT represents the report category, e.g., P=priced, 
U=unpriced. 

In the hereinafter described manner, the GRTL 

10 message is received by the StarWRS proxy server 

application 250' to enable the RM server 250 to perform 
the query into the RM Informix database having the data 
associated with the request. Specifically, after 
selecting the Report Requester from the browser or the 

15 Toolbar, a WRSApp object is launched. At its creation, 

the WRSApp object creates a DataManager object to guide 
the data and which initiates a CommunicationManager 
object to manage all communication between the client 
and the server. The CommunicationManager utilizes a 

20 RptManagerMsg object to create: 1) a GRTL; 2) a 

WRSCommWrapper for direct communication with the 
backend; and, 3) a WRSReportManagerUtilParser to format 
the data returned. In response, the Report Manager 
creates a Dispatcher object, which contains the 

25 business logic for handling metadata messages at the 

back-end and utilizes the services of a RMParser class. 
Upon determining that the client has sent a valid 
message, the appropriate member function is invoked to 
service the request. Upon receiving the message, the 

30 Report Manager creates the Parser object (RMParser) 

which takes the message apart and invokes a validation 
object which validates the message. 
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In response to the GRTL message, the data 
returned by the Report Manager server 250 for this 
particular request may include the following data in 
metadata format as follows: 

SRTL<ERROR=0 , REPORTS = <RptCategoryDescriptionl 
=<RptTitlel. 1, RptTemplateIDl.1, RptCategoryTypel . 1> , 
<RptTitlel.2, RptTemplateID1.2, RptCategoryTypel. 2» , 
<RptCategoryDescription2 =<RptTitle2 . 1, RptTemplatelD2 . 1 , 
RptcategoryType2 . 1> , <RptTitle2 .2 , RptTemplateID2 . 2 . 
RptCategoryType2.2», ~ 
<RptCategoryDescription#n=<RptTitle#n.n, 
RptTemplateID#n.n, RptCategoryType#n.n> , <RptTitle#n.n, 
RptTemplatelD#n . n . RptCategoryTypettn. n>» 

wherein RptID# indicates a standard report template ID. 
RptTitle# indicates the standard report template title. 
RptCategoryfl indicates the report category, e.g. 
Monitor Usage, Analysis Traffic, Historical. Executive 
Summary, Call Detail, etc.; and, RptDescript indicates 
the standard report template description displayed to 
the user. Thus, for each Report Template Category, 
there will be the list of reports with each entry 
containing a Report Template Title, a Report Template 
Description and the Report Template ID. 

The SRTL message is sent from the StarWRS RM 
proxy server to the report requestor for presentation 
to the customer. Specifically, the SRTL response is 
built inside the esgl wrapper function after obtaining 
the necessary information through the stored procedure 
from the Report Manager Informix database. The Report 
Manager creates the RMServerSocket object and sends the 
SRTL message back to the client. 
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To retrieve details of the standard report 
template, the GRTD request message request is sent 
having content shown in the table in Appendix A. When 
specified, the Report ID field indicates an existing 
report that a user may wish to edit. 

The SRTD response generated by the RM server 
is formatted in metadata as follows: 
< Report Template ID=ID#, 

NODEl=<node levell, label valuel, assigned unique 
screen identif icationl , >, 

NODE2=<node level2, label value2, assigned unique 
screen identif ication2 , <control ID2.1, field- 
value2.1, data location2 . 1>, <control ID2.2, field 
value2.2, data location2 .2> , <..,..,..»* 

N0DE#n=<node levelttn, label value#n, assigned unique 
screen identif icationttn, <control ID#n.l, field 
value#n.l, data location#n. 1> , <control ID#n.2, field 
value#n.2, data location#n. 2» 

In the SRTD message, the MetaTreeData Label 
fields include such values as General, Report Name, 
Report Description, Scheduled Execution, etc. The 
MetaCtrllnfo MetaField Value fields may be blank or may 
contain the selection options available to the user. 
This information is taken from the report template 
database. 

As another example, when a report request is 
submitted to retrieve a full list of user created 
reports from a user report table, i.e., a template list 
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for a particular report product, category, and type, 
the example metadata format is as follows: 

GURL<USERID= j eanvnet2 , RPTTMPID=1 , ENTPID=00022924 , PRODUCT=T 
, DATACAT=U> 

with UserlD and ReportTemplatelD fields specified. 
Specifically, this process entails invoking the 
Communication Manager object to communicate with the RM 
server in order to obtain a SURL metadata message. The 
CommunicationManager utilizes the RptManagerMsg object 
to create: 1) a GURL, 2) a WRSCommWrapper for direct 
communication with the backend, and, 3) a 
WRSReportManagerUtilParser to format the data returned. 
The parser returns a hash table containing the User 
Report List. At the RM server, the Report Manager 
creates an Dispatcher object that contains the business 
logic for handling metadata messages at the back-end 
and utilizes the services of the RMParser class. Upon 
determining that the client has sent a valid message, 
the appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates a Parser object (RMParser) which takes 
the message apart and invokes a validation object which 
validates the message. 

In response to the GURL request, the data 
returned is taken from a user report table in the RM 
server database. The generic SURL message in Metadata 
format returned by the RM server 250 includes the 
following information: 
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REPORTS = <UserRptCategoryl = <UserRptTitlel , 
UserRptlDl, activeflag, report type, statusdate 
» # <UserRptCategory2 = <UserRptTitle2 , 
UserRptID2, activeflag, report type, 
statusdate>>,.~ <UserRptCategory#n = 
<UserRptTitle#n, UserRptID#n, activeflag, report 
type, statusdate»> 

wherein for each user report category, there is a list 
of reports where each entry contains a UserRptID# 
indicating a user -defined report template ID, a 
UserRptTitle# indicating the user's report template 
title, and a UserRptCategory# indicating the user 
report category. Specifically, the SURL response is 
built inside an esql wrapper function after obtaining 
the necessary information through a stored procedure 
from the Informix database. The Report Manager creates 
the RMServerSocket object and sends the SURL message 
back to the client. 

To retrieve the details of a specific user's 
report, the GURD message is sent having data as 
contained in the table shown in Appendix A. 
Specifically, when the user selects a report from the 
Inventory List on the Report Requestor, a Communication 
Manager object is invoked to communicate with the RM 
server in order to obtain a SURD metadata message. The 
CommunicationManager object first utilizes the 
RptManagerMsg object to create: 1) a GURD metadata 
message, 2) a WRSCommWrapper for direct communication 
with the backend, and 3) the RSReportManagerUtilParser 
to format the data returned. The parser organizes the 
data into a series of nodes which are utilized to 
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create the report builder tree on the report requestor 
customization screen. Later this data will be extracted 
from the node and used to construct the screen related 
to the node. The Report Manager server creates the 

5 MCIDispatcher object which contains the business logic 

for handling metadata messages at the back-end and 
utilizes the services of the RMParser class. Upon 
determining that the client has sent a valid message, 
the appropriate member function is invoked to service 

10 the request. The Report Manager, upon receiving a 

message, creates the Parser object (RMParser) which 
takes the message apart, invokes a validation object 
which validates the message and builds a response 
inside the esql wrapper function after obtaining the 

15 necessary information through the stored procedure from 

the Informix database. The Report Manager creates the 
RMServerSocket object and sends the SURD/SRTD message 
back to the client. The responsive SURD metadata 
message corresponding to a retrieve user report detail 

20 (GURD) request has the following metadata syntax: 

< Report Template ID=ID#, 

N0DEl=<node levell, label valuel, assigned unique screen 
25 identif icationl, >, 

N0DE2=<node level2 , label value2, assigned unique screen 
identif ication2, <control ID2.1, field value2.1, data 
location2 . 1>, <control ID2.2, f ield value2 . 2 , data 
30 location2 .2>, <.., », 
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NODE#n=<node level#n, label valuetfn, assigned unique 
screen identif icationttn, <control ID#n.l, field value#ri.l, 
data location#n.l>, <control ID#n.2, field value#n.2, data 
location#n.2>, <..,♦.,. 

This response thus may include the report information 
having detailed items including: UserReportID (UserlD) , 
User's report name (UserName) , product (UserProd) , 
Threshold (UserThreshold) , User Report Description 
(UserDescript) , Report Columns (UserFields) , Report 
column headings (UserHeaders) , and, in addition, 
customization options with fields indicating, inter 
alia, columns to display (UserHeaders) , user -defined 
criteria (UserCriteria) , a sort order (UserOrder) and 
scheduling selections (UserSched) , the last update of 
this report (UserLastUpdate) and, the Report status (if 
adhoc) (UserStatus) , etc. 

If a request is made to add a user-created report 
to a User_report table maintained by the RM Server 250 
and the RS server 260, the ARD metadata message having 
fields defined in the table provided in Appendix A is 
processed by the RM server 250, as indicated at step 
628, Figure 13(a) . An example message in metadata 
format to initiate the addition of a user- created 
report for ODS (Inbound/ Outbound) reporting data is as 
follows: 

ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=90, 
NAME=City Summary 

Outbound, PRODUCT=S , CATEGORY=Analyze Traffic , 
THRE SHOLD= <RECCOUNT= 2 0 > , SCHEDULE=A< START= 19980602 
0000, END= 19980715120O, RANGET YPE= 1 , SCHEDTYPE= A , TI 
MEZONE=45,BILLING=INBOUND«90000003 , 90000003><NA, 
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NA><NA, NA>>INBOUND<<9 0000004 , 90000004><NA, NA><NA # 
NA»,CARDNO=<654654*-5465465465465465>,IDAC=<4 654 

6546*~1246>,GEO=GEO«001, 001 

USA/W0RLDZ0NE1XNA , NA> <NA , NA><NA , NA><NA, NA»GEO« 
001,001 

USA/W0RLDZ0NE1><C0 , CO><NA, NA><NA , NA><NA, NA» , OACC 
ESS=<4~1> , ODISTRANGE=<A~F> , OUSAGE=<5~4> , SORTBY=<5 
4D> ,DESCRIPTION==This report ■ summarizes call 
detail by the terminating city and state (USA) / 
province (CA) . The report is based on the 
date/ time ranges and report criteria 
selected. ,COLUMNS=<54~55~67~62~36~61~5 8~63~64~66~ 
65> , ACTIVE=1 , TOTALMODE=0 , EMAIL=0 , PAGE=0 , 
LANG=1234, CURR=2345> 

In this example, the "NAME" field refers to the 
Report Name (e.g., city summary); the "PRODUCT" 
field refers to the report product (Vision) ; the 
"THRESHOLD" field refers to the record count; the 
"DESCRIPTION" field refers to the report 
description; the "COLUMNS" refers to the number of 
columns specified for a report by the user; the 
"BILLING" field refers to the specified report 
billing entitlement, i.e., billing hierarchy; the 
"IACCESS" field refers to the inbound access type 
and the "OACCESS" refers to the outbound access; 
the "SORTBY" field indicates the report column 
sorting customization with "A" indicating column (s) 
having data to be sorted in ascending order and, 
"D" indicating column (s) having data to be sorted 
in descending order; the "SCHEDULE" field referring 
to the scheduling type, e.g., with "A" indicating 
an ad-hoc report, and the user specified date range 
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on which to report as indicated by the "START" and 
"END" fields, and additionally, the scheduling 
frequency information in the case of a recurring 
report; the SUBTOTALCOLUMNS field, referring to the 
5 report columns having data to be sub totaled; and, 

the "EMAIL" and "PAGE " fields indicating reporting 
notification via e-mail or paging, respectively. 

Furthermore, for each of the metadata 
messages in Appendix A, including the Delete Report 
10 Definition (DRD) , copy report definition (CRD) , and 

update report scheduling (URS) messages, the report 
manager server 2 50 responds to the Report Requestor 
with the processing results. In the case of a copy 
report, a new User Report ID is assigned and 
15 returned by RM. When editing an existing StarODS 

(priced call data) report, the user may make 
changes to the Report Title, the Report 
Description, the Report scheduling, the 800 numbers 
and thresholds, and may customize number of rows, 
20 report columns, access codes, access types, billing 

location, geographic location, paging notification, 
and e-mail notification. More specifically, when 
the user selects a report from the inventory list 
or a new report, an WRSEdit Screen is launched to 
25 provide the editing capabilities which are 

available for the report format. WRSedit guides 
the screens through the process of retrieving the 
screens' data. Some of the screens need data which 
has not yet been retrieved, such as 800 numbers or 
30 geographic locations. These screens manage the 

requests to the DataManager object to create the 
get pick list (GPL) message (Appendix A) , which 
launches the CommunicationManager object to perform 
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this task. The CommunicationManager utilizes the 
RptManagerMsg object to create the GPL, the 
WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtilParser to 
format the data returned. In response, the Report 
Manager server creates the MCIDispatcher object and 
invokes the MCIRMParser class . Upon determining 
that the client has sent a valid message, the 
appropriate member function is invoked to service 
the request. The Report Manager, upon receiving a 
message, creates the Parser object (RMParser) which 
takes the message apart and a validation object is 
invoked which validates the message. The response 
is built inside the esql wrapper function after 
obtaining the necessary information through the 
stored procedure from the Informix database. The 
Report Manager creates the RMServerSocket object 
and sends the GPLA message back to the client. 

Having described the functionality of 
selecting and/or generating a report and 
customizing it, reference is now had to the process 
for running the report request in StarODS. 
Particularly, in the preferred embodiment, the user 
may select a save and exit report option, or a save 
and run report option. In either scenario, an 
WRSEdit object enables a WRSScnMgr object to save 
the report to the RM server* The WRSScnMgr object 
launches each screens save method which 
communicates with the DataManager object to place 
the screens data in its corresponding WRSNode. 
Once all of the WRSNode objects have been updated, 
the WRSScnMgr object calls the DataManager object's 
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SaveReport method to build a hash table to contain 
all o£ the report's data. The CommunicationManager 
utilizes the RptManagerMsg object to create the ARD 
metadata message from the hash table, the 
WRSCommWrapper for direct communication with the 
backend, and the WRSReportManagerUtilParser to 
handle any errors thrown by the server. The Report 
Manager creates the Dispatcher object r and utilizes 
the services of the RMParser class and validation 
objects. Upon determining that the client has sent 
a valid message, the appropriate member function is 
invoked to service the request. The response is 
built inside the esql wrapper function after 
obtaining the necessary information through the 
stored procedure from the RM database. The Report 
Manager creates the RMServerSocket object and sends 
the ARDA message back to the client. 

As illustrated in Figure 13 (a) , at step 
630, in reference to user selection of a Save and 
Run report option, the report is marked as 
scheduled and saved in a user_table in the Report 
Scheduler server 260 via the Report Manager. 
Subsequently, as indicated at step 630, the Report 
Scheduler server 260 generates an ARD message 
(Appendix D) and sends the ARD message to StarODS 
DSS server for which the DSS has a predefined 
interface, as described herein. 

Next, as indicated at step 632, the DSS 
receives the request and acknowledges receipt. 
Specifically, when the request is received it is 
first validated with StarOE to ensure that the user 
is entitled to receive information about the 
selected product corp and number (s). Once the 
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request passes validation, the DSS IAIO reads the 
header to determine which Data Mart will ultimately 
be queried. It then parses the metadata into a 
format which the COTS software can readily convert 
into a SQL statement, as indicated at step 635, 
Figure 13 (b) , and adds the report to the DSS report 
queue based upon type (Daily, Weekly, Monthly, 
Adhoc) and associated DataMart, as indicated at 
step 638. It should be understood that at this 
point, the request has been flagged as submitted in 
the RM database, as indicated at step 633. 

From this point forward, DSS activity is 
controlled by a control process and progress or 
errors are logged internally in the DSS system. 
This control process includes logic enabling the 
prioritization of report requests and application 
of rules defining the order in which they should be 
executed. Thus, at the appropriate time, depending 
on the type or report, reporting period and other 
parameters, the Information Advantage query engine 
selects the report from the queue, as indicated at 
step 640, which action is logged in the report 
status table (Appendix I) as indicated at step 642. 
The SQL statement is then built by Decision Suite™ 
and routed to the appropriate data mart for 
execution in the manner as described herein, as 
indicated at step 643. The query engine generates 
the SQL statement from the metadata and executes 
the report which action is logged in the report 
status table as indicated at step 645. Next, as 
indicated at step 64 8, the query results are 
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returned, and, a post- SQL formatting process is 
invoked. 

More particularly, as shown in Figure 
12(b), a Formatter module 395 may perform various 
report result transformations including: 1) 
Converting of column headers generated by 
Information Advantage® into appropriate column ids 
that are recognizable to the StarWRS client viewer 
functionality (as indicated at step 650, Figure 
13(b)); 2) Provide subtotaling for specific 
requested "subtotal by" columns in the format 
required by the StarWRS client interface (as 
indicated at step 653, (Figure 13(b)) and provides 
report -based totals as requested by customer; 3) 
converting binary stream data file to ASCII text 
file (as indicated at step 655, Figure 13(c)); 4) 
implementing Replace logic, e.g., replacement of 
"TAB" delimiters with appropriate "Comma" field 
delimiters (as indicated at step 657 Figure 13(c)); 
5) implementing Repeat/Padding logic, i.e., 
identifying compressed columns/values and 
decompressing (or repeating) the values that were 
compressed; 6) providing alphanumeric translations 
for any encoded data elements returned in the 
result set data file (as indicated at step 659, 
Figure 13(c)); and, 7) adding new computed/derived 
columns, e.g., percents, averages of column data 
values,, etc., as requested by customers on specific 
reports . 

Particularly, as shown in Figure 12(b), 
the Formatter process 395 reads the *.hdr files and 
*.data files from the Decision Suite™ result set to 
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obtain respective column names and report data. 
Particularly, the formatter process for converting 
Column Headers from Information Advantage® column 
header names to column ids implements a lookup of 
5 column ids in a column__id's table, shown in 

Appendix I , based on column header names . 

Then, the formatter process reads the request 
table 390 for total/subtotal, threshold, etc. 
information associated with the current report 
10 request and determines any other formatting 

features to be enabled for a particular result set. 
As shown in the example Request Table of Appendix 
I, parameters passed to the formatter module 
indicate any report request specific details that 
15 are required by the Formatter. For example, for 

report totals, a "total_mode" variable is used to 
indicate if report totals and/or sub- totals should 
be included. Particularly, Column IDs 
representing the data columns upon which 
20 subtotaling is based are passed as parameters to 

the Formatter process 395 and are referred to as 
"Break Columns" . At appropriate changes in values 
for these break columns, the formatter generates a 
subtotal line for subtotaling the applicable 
25 additive facts including, for example, Call Amount, 

Call Duration, and Call Count. 

Furthermore, the formatter reads a Column 
id table 396 (detailed in Appendix I) to determine 
data types and if any data translations are needed. 
30 As computed/derived columns may be 

included or excluded from customer report requests, 
the Formatter process 395 for calculating new 
computed/derived columns on specific customer- 
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requested reports are provided on a report request 
basis. Example types of derived columns include: 
1) Percents, e.g., based on the additive data facts 
pertinent to the report request and are typically 
based on report totals and row amounts for Call 
Amount, Call duration, and Call Count; 2) Row -wise 
derived data elements as requested, which represent 
data elements computed based on original additive 
data elements on a row by row basis (i.e., column 
x/column y for each row in the result data file) 
and typically include average calculations such as 
Average of Minutes per Call, Average Amount per 
Call, and Average Amount per Minute. Appendix I 
illustrates a derived column "percent" calculation 
indicated in the Column ID table showing an 
equation for calculating a value of a particular 
value (C36) divided by a column total (CT36) x 100. 

The Formatter process 395 may 
additionally perform alphanumeric translations for 
any encoded data elements returned in the result 
set data file by implementing appropriate lookup in 
a Translation table 397, such as the example 
Translation Table provided in Appendix I, and 
replacing the code. 

Referring back to Figure 13(c), after, 
formatting the report, as indicated at step 660, a 
message is sent to the control process to update 
the request status table 391. It should be 
understood that, if a failure occurs during 
formatting, the error log is updated and a status 
message sent to the request status table 391, as 
well. Then, as indicated at step 665 (Figure 
13(c)), the formatter 395 creates a *.csv (Comma 
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Separated Value) or .txt file, gives the file a 
unique name and saves the file. Preferably, a 
*.csv is the file generated if the report is 
successfully generated. As indicated at step 668, 
the *.csv report/data file is then "pushed", 
implementing FTP, to the StarODS server's directory 
on the Inbox server 270. The StarODS server 400 is 
responsible for generating unique file names within 
their directory on the Inbox server 270. For 
example, the following directory and file naming 
conventions used for reports generated by the 
StarODS server are labeled inbox\f iles\ods with 
text files having the suffix *.txt or *.txt_zip 
(compressed) , and comma separated files having a 
suffix *.csv or *.csv_zip (compressed). 

Finally, as indicated at step 670, once 
the file has been successfully transferred to the 
Priced reporting directory on the Inbox server, and 
the request status table 391 appropriately updated 
at step 675, the NRL process (Figure 1Kb)) 
generates and transmits an NRL message to the RM 
Server 250 notifying it of the report file name and 
location in the Inbox, requestor information, and 
if the transfer was successful. This is 
accomplished by using a "NRL" metadata message. 

Appendix B provides a table comprising 
the Notify Report Location parameters used for the 
NRL Metadata messaging sent by StarODS fulfilling 
server to the RM Server 250 when a requested report 
is complete. An example NRL message sent from the 
ODS server 400 to the RM server 250 is as follows: 

NRL<TYPE=S im - Msg -40, ENTPID= 00022924, USERID=dorod , 
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STDRPTID=40 , USERRPTID=3415 , REQUESTID=20341 , COMPRESS=0 
,LOC=/inbox/files/testODS/STDRPTID43TM_082598_084920. 
CSV, FSIZE=389 , PRESORTED=0> 

An NRLA response is sent back to the DSS 
as shown in Appendix B. 

Once the RM server 250 has received the 
NRL message from the fulfilling server, it verifies 
the file's presence and builds a metadata file, 
e.g., by compressing the appropriate metadata (for 
displaying the report) into a .MTD file. This .MTD 
file is utilized by the Report Viewer to know how 
to display the report. The Report Manager server 
creates a file including the metadata using the 
same file name as the report/data file, but having 
the following suffix: *.mtd or *.mtcL_zip indicating 
a metadata or compressed metadata file, 
respectively. 

Appendix F details the parameters that 
are passed in the GET METADATA messaging for 
indicating to the Report Viewer how to display a 
requested report. For example, a GET METADATA 
message corresponding to an Priced TVS fulfilling 
server report is as follows: 

<METADATA=<CRITERIA=<Name=UsageSummary292AADescriptio 
n= This report summarizes calls based on call type.*A 
Report_Level=<INBOUND«90000001,90000001><NA,NA><NA,N 

A» 

INBOUND<<90000002, 9 0000002>< , >< , >>> A AOptions==*ASchedu 
ling_Inf ormation= *AOne_Time=AADa tes=<0 6 701/199 800:00/ 
-07/01/199800: 00, >AATimezone=EST,Lang=1234 ,Curr=2345> 
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DEFAULT_GRAPH_MODE= 0 a ADEF AULT_GRAPH_TY PE=0 AADEFINE_X_AXI S = 0 

AAX_AXIS_COLUMN= aaDEFAUL T_Y_COLUMNS=<> A A 
COLUMN_DISPLAY_ORDER=<105AA114AA67AA62AA36AA61AA58AA6 

3 a A64 AA6 6 a A6 5 > AASORT_ALLOWED= 1 a APRESORTED=0 a A 

5 PRESUBTOTALED=1AATOTALMODE=OAASORT_COLUMN S=<105A>aa 

SUBTOTAL_COLUMNS=<>AASELECTED_SECTION=0AA 
MET AC 0 LUMN = < MET A_C OLUMN_I D = 1 0 5 a A 
COLUMN_LABEL=Usage 

DescriptionAADATATYPE=SAADECIMAL=OAA 
1 0 HIDEABLE= 1 A AGRAPHABLE=0 A AWIDTH=20 a ACALCULATE=0 a A 

CALCULATE_EXPRESSION=>AAMETACOLUMN=<META_COLUMN_ID=ll 

4 A A 

COLUMN_LABEL=Range/DistanceDescriptionAADATATYPE=SAAD 
ECIMAL=0AAHIDEABLE=1AAGRAPHABLE=0AAWIDTH=20AACALCULAT 

15 E=0 A A 

CALCULATE„EXPRESSION=>AAMETACOLUMN=<META_COLUMN_ID«67 

AA 

COLUMN_LABEL=CallsAADATATYPE=IAADECIMAL=0AAHIDEABLE=l 
AA 

20 GRAPHABLE=1AAWIDTH=7AACALCULATE=0AACALCULATE_EXPRESSI 
ON=> 

AAMETACOLUMN-<META__COLUMN_ID=62 A ACOLUMNL.LABEL=% 
CallsAA 

DATATYPE=N A ADEC IMAL= 1 A AHIDEABLE= 1 a AGRAPHABLE= 1 a AWIDTH 
25 =7aa 

CALCULATE = 0 a ACALCULATE_EXPRES S I ON=> a A 

METACOLUMN=<META_COLUMN_ID=36AACOLUMN_LABEL=MinutesAA 
DATATYPE=N a ADEC IMAL= 1 a AHIDEABLE= 1 A AGRAPHABLE= 1 A AWIDTH 
= 8AA 

30 CALCULATE= 0 A AC ALCULATE_EX PRESS ION=> a A 

METACOLUMN=<META_COLUMN_ID=6 1AAC0LUMN_LABEL=% MinAA 

DATATYPE=NAADECIMAL=1AAHIDEABLE=1AAGRAPHABLE=1AA 

WIDTH=5AACALCULATE=0AACALCULATE_EXPRESSION=>AA 
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METACOLUMN=<META_COLUMN_ID=58AACOLUMN_LABEL»AmountAAD 
ATATYPE=C A ADEC IMAL C 2 A AHIDEABLE= 1 A A 

GRAPHABLE=1AAWIDTH=7AACALCULATE=0AACALCULATEL_EXPRESSI 
0N=> 

AAMETAC0LUMN=<META_C0LUMN_ID=6 3 AACOLUMN_LABEL=% Amt a A 
DATATYPE=NAADECIMAL=1AAHIDEABLE=1AAGRAPHABLE=1AAWIDTH 
=5AA 

CALCULATE=0 A ACALCULATE_EXPRESSION=> A A 
METACOLUMN= <META L _COLUMN_ID= 6 4 a ACOLUMN_L ABEL= Avg 
Min/Call 

a ADATATYPE=N A ADEC IMAL=2 A AH IDE ABLE— 1 A AGRA PHABLE= 1 A A 
WIDTH=12AACALCULATE=0AACALCULATE_EXPRESSION=>AA 
METAC0LUMN=<META^C0LUMN_ID=6 6 A ACOLUMN_LABEL=Avg 
Amt/Call A A 

DATATYPE=NAADECIMAL=2AAHIDEABLE=1AAGRAPHABLE=1AAWIDTH 
= 12 

a A C ALCULATE= 0 a AC ALCULATE_EX PRE S S ION=> a A 
METAC0LUMN=<META_C0LUMN_ID=6 5 A ACOLUMN_LABEL=Avg 
Amt/Min A A 

DATATYPE=N A ADECIMAL=2 A AHIDEABLE=1AAGRAPHABLE=1AA 
WiDTH= 1 1 a ACALCULATE= 0 a ACALCULATE_EXPRES S ION=> » 
*<METADATA= <CRITERIA= <Name=My Report, 
Total=Totals are located at the bottom of the 
report., Description=My report description, 
Number_Dialed=<800#l, 800#2, 800#n>, 
Scheduling_Inf ormation= Recurring, Dates= 
Monthly» DEFAULT_GRAPHJ40DE=1, 
DEFAULT_GRAPH_TYPE= 1 , DEFINE_X_AXI S= 1 , 
X^AXIS_C0LUMN=2 , DEFAULT_Y_C0LUMNS=<5 , 6> , 
C0LUMNJDISPIAY_0RDER=<1 , 2 , 3 , 4 , 5 , 6> , 
C0LUMN_ST0RED_0RDER=<4 , 3 , 2 , 5 , 6 , 1> , 
S0RT_ALL0WED=1, PRESORTED = 1, T0TALM0DE=3 , 
SUBT0TC0L=<5 , 6> , SELECTED SECTI0N=1 , 
METAC0LUMN=<META_C0LUMN_ID=1 , COLUMN_LABEL=name , 

-86- 



SUBSTTTUTE SHEET (RULE 26) 



DATATYPE=S, DECIMAL=0 , HIDEABLE=1 , GRAPHABLE= 0 , 
WIDTH=10, CALCULATE=1 , CALCULATE_EXPRESSI0N=<4 / 
7»» 



Once the metadata file corresponding to 
the requested report is build by the Report 
Manager, the RM ftp's the .MTD file to the Inbox 
server. The RM server additionally updates a 
User_report table status field with a status "C 
indicating completion. 

Once the Report Manager has updated the 
status field, the RM server 250 then adds the 
report to the user's Inbox. 

Appendix C provides a table showing the 
fields for the metadata messaging between the RM 
server 250 and the Inbox server 270 for adding an 
item into the StarWRS system Inbox server 270, and 
the respective acknowledgment message format back 
from the Inbox server. In the "A w message found in 
Appendix C, the "LOC" field includes information 
about where the report data is located. For 
example, a metadata message indicating to the Inbox 
server that a priced ODS server report is available 
is shown as: 

A<CATEGORY=R , TYPE=traf f ic , REQUESTID=32197 , USER 
ID=LynneLevy2 , RPTID=15 0 , PRI0RITY= , COMPRESS=0 , U 
NOTIFY=0 , MMADDR= , MMTEXT= , PGT= , PGPIN= , FGTXT= , RP 
TCATEGORY=Service Location & Hour, 
L0C=/inbox/f iles/ods/902512294STDRPTID10 .CSV, E 
NTPID=103244 88,RQSTDT=1998-01-02 
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15 : 18 , FSIZE-37 05 , RPTTITLE=Summary by Service 
Location and Hour,MSIZE=3322> 

Particularly, the RM server supplies a 
metadata "A" message. to the Inbox indicating the 
FTP file location. Via the report viewer, the 
report is now available for viewing, downloading, 
saving, or printing by the user. Particularly, as 
shown in the exemplary nMCI home page in Figure 4 , 
the nMCI Interact Message Center icon 77 may be 
selected which will cause. the display of a web page 
including the message center dialog window. From 
the message center dialog windoe, a user may select 
from among three tabs, one of which, a reports tab, 
enables the retrieval of both a data file and a 
metadata file from the Inbox Server corresponding 
to those reports that have been run and available 
for customer viewing. Information provided for 
display by the message center display 325 is 
provided by the User_table which keeps track of the 
status of all reports for a particular user. By 
double -clicking a chosen report, a report viewer 
application is enabled to display the chosen report 
on a web -page. To view the report the user selects 
the report and, the report metadata and the 
appropriate viewer are uploaded to the user 
(client) workstation. 

As mentioned herein with respect to 
Figure 3, the messages created by the client Java 
software are transmitted to the StarWeb (DMZ) 
Server 44 over HTTPS - For incoming 
(client • to -server) communications, the DMZ Web 
servers 44 decrypt a request, authenticate and 
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verify the session information. The logical 
message format from the client to the Web server is 
shown as follows: 



5 | | TCP/IP | | encryption | | http | | web header | | 

dispatcher header | | proxy- specific data | | 

where " | I " separates a logical protocol level , and 
protocols nested from left to right. Figure 14 

10 illustrates a specific message sent from the client 

browser to the desired middle tier server for the 
particular application. As shown in Figure 14, the 
client message 340 includes an SSL encryption 
header 342 and a network- level protocol HTTP/POST 

15 header 344 which are decrypted by the DMZ StarWeb 

Server(s) 44 to access the underlying message; a 
DMZ Web header 346 which is used to generate a 
cookie 341 and transaction type identifier 343 for 
managing the client/server session; a dispatcher 

20 header 34 5 which includes the target proxy 

identifier 350 associated with the particular type 
of transaction requested; proxy specific data 355 
including the application specific metadata 
utilized by the target proxy to form the particular 

25 messages for the particular middle tier server 

providing a service; and, the network- level 
HTTP/POST trailer 361 and encryption trailer 366 
which are also decrypted by the DMZ Web server 
layer 44 . 

30 After establishing that the request has 

come from a valid user and mapping the request to 
its associated session, the request is then 
forwarded through the firewall 55b over a socket 
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connection 33 to one or more decode/dispatch 
servers 4 6 located within the corporate Intranet 
60. The messaging sent to the Dispatcher will 
include the user identifier and session 
information, the target proxy identifier, and the 
proxy specific data. The decode/dispatch server 46 
authenticates the user's access to the desired 
middle- tier service. 

As shown in Figure 14, the StarWeb server 
forwards the Dispatcher header and proxy- specif ic 
data to the Dispatcher, "enriched" with the 
identity of the user (and any other session- related 
information) as provided by the session data/cookie 
mapping, the target proxy identifier and the proxy - 
specific data. The dispatch server 46 receives the 
requests forwarded by the Web server (s) 44 and 
dispatches them to the appropriate application 
server proxies. Particularly, as explained 
generally above with respect to Figure 7, the 
dispatch server 46 receives request messages 
forwarded by the DMZ Web servers and dispatches 
them to the appropriate server proxies. The 
message wrappers are examined, revealing the user 
and the target middle -tier service for the request. 
A first- level validation is performed, making sure 
that the user is entitled to communicate with the 
desired service. The user's entitlements in this 
regard are fetched by the dispatch server from 
Order Entry server 280 at logon time and cached. 
Assuming that the Requestor is authorized to 
communicate with the target service, the message is 
then forwarded to the desired service's proxy, 
which, in the accordance with the principles 
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described herein, comprises: 1) a report manager 
proxy 250' corresponding to the RM Server 250, 2) 
a report scheduler proxy 260 1 corresponding to the 
RS Server 260, and 3) an inbox server proxy 270' 
5 corresponding to the. Inbox Server 270. Bach of 

these proxy processes further performs: a 
validation process for examining incoming requests 
and confirming that they include validly formatted 
messages for the service with acceptable 
10 parameters; a translation process for translating a 

message into an underlying message or networking 
protocol; and, a management process for managing 
the communication of the specific customer request 
with the middle- tier server to actually get the 
15 request serviced. Data returned from the middle - 

tier server is translated back to client format, if 
necessary, and returned to the dispatch server as a 
response to the request. 

Figures 15(a) and 15(b) are schematic 
20 illustrations showing the message format passed 

between the Dispatcher 46 and the application 
specific proxy (Figure 15(a)) and the message 
format passed between the application specific 
proxy back to the Dispatcher 46 (Figure 15(b)). 
25 As shown in Figure 15(a), all messages between . the 

Dispatcher and the Proxies, in both directions, 
begin with a common header 110 to allow leverage of 
common code for processing the messages. A first 
portion of the header includes the protocol version 
30 115 which may comprise a byte of data for 

identifying version control for the protocol, i.e., 
the message format itself, and is intended to 
prevent undesired mismatches in versions of the 
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dispatcher and proxies . The next portion includes 
the message length 120 which, preferably, is a 32- 
bit integer providing the total length of the 
message including all headers. Next is the 
echo/ping flag portion 122 that is intended to 
support a connectivity test for the dispatcher - 
proxy connection. For example, when this flag is 
non-zero, the proxy immediately replies with an 
echo of the supplied header. There should be no 
attempt to connect to processes outside the proxy, 
e.g. the back-end application services. The next 
portion indicates the Session key 125 which is the 
unique session key or "cookie" provided by the Web 
browser and used to uniquely identify the session 
at the browser. As described above, since the 
communications middleware is capable of supporting 
four types of transport mechanisms, the next 
portion of the common protocol header indicates the 
message type/mechanism 130 which may be one of four 
values indicating one of the following four message 
mechanisms and types: 1) Synchronous transaction, 
e.g., a binary 0; 2) Asynchronous request, e.g., a 
binary 1; 3) Asynchronous poll/reply, e.g., a 
binary 2; 4) bulk transfer, e.g., a binary 3. 

Additionally, the common protocol header 
section includes an indication of dispatcher - 
assigned - serial number 135 that is unique across 
all dispatcher processes and needs to be 
coordinated across processes (like the Web cookie 
(see above)), and, further, is used to allow for 
failover and process migration and enable 
multiplexing control between the proxies and 
dispatcher, if desired. A field 140 indicates the 
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status is unused in the request header but is used 
in the response header to indicate the success or 
failure of the requested transaction. More 
complete error data will be included in the 
specific error message returned. The status field 
140 is included to maintain consistency between 
requests and replies. As shown in Figure 16(a), 
the proxy specific messages 375 are the metadata 
message requests from the report requestor client 
and can be transmitted via synchronous, 
asynchronous or bulk transfer mechanisms. 
Likewise, the proxy specific responses are metadata 
response messages 3 80 again, capable of being 
transmitted via a synch, asynch or bulk transfer 
transport mechanism. 

It should be understood that the 
application server proxies can either reside on the 
dispatch server 46 itself, or, preferably, can be 
resident on the middle- tier application server, 
i.e., the dispatcher front end code can locate 
proxies resident on other servers. 

As mentioned, the proxy validation 
process includes parsing incoming requests, 
analyzing them, and confirming that they include 
validly formatted messages for the service with 
acceptable parameters. If necessary, the message is 
translated into an underlying message or networking 
protocol. A list of Report Manager and Inbox proxy 
error messages can be found in Appendix E. If no 
errors are found, the proxy then manages the 
communication with the middle- tier server to 
actually get the request serviced. The application 
proxy supports application specific translation and 
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communication with the back-end application server 
for both the Web Server (java applet originated) 
messages and application server messages. 

Particularly, in performing the 
verification, translation and communication 
functions, the Report Manager server, the Report 
Scheduler server and Inbox server proxies each 
employ front end proxy C++ objects and components. 
For instance, a utils.c program and a C++ 
components library, is provided for implementing 
general functions/objects. Various C++ parser 
objects are invoked which are part of an object 
class used as a repository for the RM metadata and 
parses the string it receives. The class has a 
build member function which reads the string which 
contains the data to store. After a message is 
received, the parser object is created in the 
RMDi spat cher. c object which is file containing the 
business logic for handling metadata messages at 
the back-end. It uses the services of an RMParser 
class. Upon determining that the client has sent a 
valid message, the appropriate member function is 
invoked to service the request. Invocation occurs 
in MCIRMServerSocket.C when an incoming message is 
received and is determined not to be a talarian 
message. RMSErverSocket .c is a class implementing 
the message management feature in the Report 
Manager server. Public inheritance is from 
MCIServerSocket in order to create a specific 
instance of this object. This object is created in 
the main loop and is called when a message needs to 
be sent and received? a Socket. c class implementing 
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client type sockets under Unix using, e.g., TCP/IP 
or TCP/UDP. Socket. C is inherited by 
ClientSocket.C: : Socket ( theSocketType, thePortNum) 
and Server Socket . C : : Socket ( theSocketType , 
5 thePortNum) when ClientSocket or ServerSocket is 

created. A ServerSocket .c class implements client 
type sockets under Unix using either TCP/IP or 
TCP/UDP. ServerSocket .C is inherited by 
RMServerSocket when RMServerSocket is created. An 
10 InboxParser .c class used as a repository for the RM 

Metadata. The class' "build" member function reads 
the string which contains the data to store and the 
class parses the string it receives. After a 
message has been received, the MCIInboxParser 
15 object is created in inboxutl.c which is a file 

containing the functions which process the Inbox 
requests, i.e, Delete, List, Fetch and Update 

(Appendix G) . Additional objects/classes include: 

Environ. c which provides access to a UNIX 
20 environment; Process. c which provides a mechanism 

to spawn slave processes in the UNIX environment; 

Daemon. c for enabling a process to become a daemon; 

Exception. c for exception handling in C++ programs; 

and, RMlog.c for facilitating RM logging. In 
25 addition custom ESQL code for RM/database interface 

is provided which includes the ESQC C interface 

(Informix) stored procedures for performing the 

ARD, DRD, DUR, URS, GRD, CRD, and GPL messages. 

The functions call the stored procedures according 
30 to the message, and the response is build inside 

the functions depending on the returned values of 
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the stored procedures. A mainsql.c program 
provides the ESQL C interface for messages from the 
report manager and report viewer. 

A list of Report Manager and Inbox proxy 
error messages can be found in Appendix E. 

Outgoing (server- to- client ) 
communications follow the reverse route, i.e., the 
proxies will feed responses to the decode/dispatch 
server, which will encrypt the client -bound 
messages and communicate them to the DMZ Web 
servers over the socket connection. The Web servers 
will forward the information to the client using 
SSL. The logical message format returned to the 
client from the middle tier service is shown as 
follows : 

| | TCP/IP | | encryption | | http I | web response | | 
dispatcher response | | proxy- specific response | | 

where || separates a logical protocol level, and 
protocols nested from left to right. The foregoing 
merely illustrates the principles of the present 
invention. Those skilled in the art will be able 
to devise various modifications, which although not 
explicitly described or shown herein, embody the 
principles of the invention and are thus within its 
spirit and scope. 
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APPENDIX A 



Retrieve Report Template List 



f Messagpi^ : ;; f 


Parameter? ^ •■■-! 
■Name:;.; , : : : / 




parameter ; y . • 

Type---v'::.'-- : 


Required'::: 


Acceptable.^ ; 
Value.; - ' ; 


GRTL 


Reauest 


Char (4) 


Yes 




PRODUCT* 


Product ID 


Chard) 


Yes 


V. C.S. T.H 


DATATYPE* 


Data Type 


Char (1) 


Yes 


R = Reports, 
D = Call Detail 
A * All data 
types 


DATACAT= 


Data Category 


Char(1) 


Yes 


P » Priced, 
U « Unpriced 


10= 


inbound/Outbo 
und 


Char(1) 


Yes 


I " Inbound, 
O * Outbound 
B = Both 


Send Renort Template List 








^ype^yiv/;;';.^ 




MAcceptabteiC:^ 


SRTL 


Response 


Char (4) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


REPORTS 3 


Data 


Char 


No 


See below 
formattina 



Get Report Template Detail 



?Mes*sage^n:^ 


^"Parameter^^ 


^Paramet^?- : '"^Ci 


:?Requji^d^ : ^^ 


vNamesL v ? : ;v;V-'',-v : l 


;HType;-;y ; . 




: Value ,o : v ; 


QRTD 


Reauest 


Char (4) 


Yes 




REPORTID= 


Standard Report 


Char (10) 


Yes 


Report ID (i.e., 




ID 




2.44) 



Send Report Template Detail 



fMe?§ag^ 


RP^ramet^^^: 1 ;-:! 


^Para'rneter:i;;^c| 


^Rep'uirecTiS; 


^Acceptable £^;-;f 




!vName^-;;: :^^; -vj 






yValue^: : '^ : y-' : 


SRTD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID- 


Template ID 


Char (10) 


Yes 
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| NODE 3 


Data 


Char 




see above I 








formatting 1 



Get User Report List 



s'Message**, j 


Parameter. : j 


Parameter.' j 

7ype-;\ 


Required^: 


^Acceptable? 
Value:, 


QURL 


Request 


Char (4) 


Yes 




USERID= 


User ID 


Char (20) 


Yes 


UserlD 


RPTTMPID 

ss 


Report t 
Template ID 


Char (10) 


Yes 


Template ID 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


PRODUCT* 


Product ID 


Char (1 


Yes 


V.C,S,T,H 


DATACAT 


Data Category 


Char (1) 


Yes 


P « Priced 
U = Unpriced 



Send User Report List 





'Paran^^ 




^Required1;| 


?:Value:;;;.iV;.;v : .^;^ 


SURL 


Response 


Char (4) 


Yes 




ERROR 3 


Error Code 


Char (4) 


Yes 


0 or error 


REPORTS* 


Data 


Char 


No 


See above 
formatting 



Get User Report Detail 



;y«U- t*;".*.^; ■>/^'7 v ,1 * \ 


;;Paramete^^ 

^Namerrr: ;; 


: ;Type^V:?--y| 




^cceptable^ue^-^ 


GURD 


Request 


Char (4) 


Yes 




REPORTID= 


User Report ID 


Char (10) 


Yes 


Report ID (i.e., 245). 
Limit on unique user 
report Ids is 
2147483647 



-98- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/20148 



Send User Report Detail 



^ Message : r:-v^ 


Parameter 


^ Parameter! T "'5 

^Type^io:; ; ':;,;:v;:w 




i Acce ptab le i Va j u e 


SURD 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


ID= 


Template ID 


Chard 0) 


Yes 




NODE- 


Data 


Char 




see above 
formattinq 



Add Report Definition 





Parameter^ 


^Type,:^>.;:- 


^equire^;^i;.^ 


vAcceppbielV 


ARD 


Request 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID - 
require 8 
characters 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e.,2,44). 


NAME= 


User's report 
name 


Char(100) 


Yes 


User's designated 
name for this 
report (e.g., My 
Lonqest Calls) 


PRODUCT* 


Product 


Char(l) 


Yes 


Vnet = V, CVNS = 
C, Vision = S, Toll 
Free«T, 
Broadband = H 


CATEGORY** 


Report category 
Description 


Char 


Yes 


Examples are: 
Analyze Traffic, 
Standard Report, 
Telecommunicate 
ns 


THRESHOLD 


Record limits 


Delimiter 


No 


holds 

RECCOUNT, 
RANKING, 
DURATION, ANI 
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RECCOUNT= 



Record count 



Char (4) 



Yes 



Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold is 
received, the 
threshold for the 
standard report will 
be used. 



RANKING* 



TVS Ranking 



Char (3) 



No 



# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be used. 



DURATION- 



TVS Duration 



Char (4) 



No 



ANI= 



TVS AN I 



Char (3) 



No 



# tor call duration 
threshold. If 
duration is not 
passed, the default 
value will be used. 



#of Items in Most 
Frequent report. If 
ANI is not passed, 
the default value 
will be used. 



SCHEDULE^ 



Report schedule Char () 



No 



If scheduling 
information is not 
received, the 
Report Manager 
wilt only store the 
report. It will not 
send a request to 
the fulfilling server. 
No overlapping 
dates will be sent 
in the start/end 
pairs. 

A = Adhoc, H = 
Hourly, D = Daily, 
W= Weekly, M = 
Monthly 



START= 



Start report 
schedule 



Char (12) 



No 



YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. 
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End report 1 Char (12) 
schedule 


No YYYYMMDDhhm 1 
1 m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. 


RANGETYPE 


Range type picked Char(1) 
by the user 


Yes if 1 = range 
Adhoc 0 = discreet 


SCHEDTYPE 


Schedule Type Char(1) 
picked by the user 


Yes A = Adhoc only 

R « Recurrinq only 


TIMEZONE= 


User's time zone I Char (3) 


Yes User's time zone 
value as received 
from StarOE 


NDIALED= 


Filter Char 


Yes for Number range I 
TVS. No for delimited by - 
all others 


BILLING= 


LJ |A»n rpHl 1 1 ("III AT 

nierarcny i wnai 


Yes for j Single or multiple 
ODS, and values from billing 
TVS hierarchy. Must at 
outbound. least include the 
No for ail Corp ID 
others 


CARDNO 


Card number 1 Char 


"Fto I Single or multiple 
values 


IDAC= 


ID/Account Codes Char 


"n5 Single or multiple 
values 


GEO= 


Geographical 1 Char 


No Single or multiple 
values from 
geographical 
hierarchy. 


IACCESS= 


Inbound Access 1 Char 


No Single or multiple j 
values of inbound I 
access 

codes(Examplc: 7) 


OACCESS= 


Outbound Access 1 Char 


No Single or multiple 
values of outbound 
I access codes 
(Example: 4) 


IDISTRANGE 


Inbound Distance 1 Char 
Range 


No Single or multiple 
values of inbound 
distance ranges 
codesfExamDle: 2) 


IUSAGE= 


Inbound Usage Char 


No Single or multiple 
values of inbound 
I usaqa (Examle: 51 1 
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ODISTRANG 
E= 


Outbound 
Distance Range 


Char 1 


No 


Single or multiple 
values of outbound 
distance ranges ( 
Example: A) 


OUSAGE= 


Outbound Usage 


Char 


No 


Single or multiple 
values of outbound 
usage ( 
Examole:2) I 


CriDTRV- 
oUnlDT- 




Char 1 


No 


If sort order is not 
received, sort 
order for standard 
report will be used. 
If sort order is 
passed, it must be 
a column ID and 
descending or 
ascending order 
(i.e.. 1A). 


DESCRIPTIO 
N= 


Description 


Char 


No 


I user's report 
description. If no 
description is 
received, the 
description for the 
standard report wilt 
be used. 


COLUMNS" 


Columns 


Char 


NO 


These are the 
columns the user 
I wants in their 
report. Field Ids 
are to be passed 
here (i.e., 5-17- 
23-44). Use 
default if not 
passed. 


ACTIVE- 


Indicates whether 
or not the report is 
scheduled 


Char(1) 


NO 


Save only ■» 0, 
Schedule = 1 , 0 is 
the default. 




1 Duration Ranos 


Char 


No 


Single or multiple 
values from the 
duration pick list 


TOTALMODE 


Totals or subtotals 
required based on 
user selection 


Char(1) 


No 


0 = None (default), 

1 ^Subtotal, 2 = 
Total, 3 = Both. 


SUBTOTCOL 


Indicates which 
columns the user 
wants subtotals on 


Char (20) 


Yes if 
TOTALMO 
DE is 1 or 

3. 


Columns to be 
subtotaled 


MMADDR= 


Email address 


Char(75) 


No 


Text 


MMTEXT= 


Messaqe 


Char(500) 


No 


Text 


PGT= 


1 PaaerSvstem 


Char<151 


I No 


I PaaerSvstem 
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PGPin= 


Pa<jer Pin 


Char(8V 


No 


Pin Number 


PGTxt= 


Message 


Char(240) 


No 


Text 


EMAIL= 


Indicates if user 
picked email. 


Char(l) 


Yes 


0 - no, 1 = yes 


PAGE= 


Indicates if User 
picked page 


Char(1) 


Yes 


0 =* no, 1 » yes 


LANG= 


Indicates the 
language a user 
picked. 


Char(4) 


No 


Default will be 
American English, 
the values are not 
defined. 


CURR= 


Indicates the 
language a user 
picked 


Char(4) 


No 


Default will be 
American Dollar, 
the values are not 
defined. 



Add Report Definition Acknowledgment 





CName^-;;;:;;;.::- 






SAcceptable^'^; .r 

kyaliier^;;-- \. 


ARDA 


Response 


Char (4) 


Yes 




ERROR" 


Error Code 


Char (4) 


Yes 


Oor error 


USERRPTID 

s 


User ReportID 


Char (10) 


No 


User Report ID 
(i.e., 245^. Umit 
on unique user 
report Ids is 
2147483647. 



Delete Report Definition 





^•Paranieier.?;>::'-;v-5:^ 






SAcc^tabl^alue^^ 


DRD 


Reauest 


Char (3) 


Yes 




USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report ID (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 



"f Message??;. 









I DRDA I Response I Char (41 I Yes I 
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ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID 

s 


User Report ID 


Char (10) 


No 


User Report ID (i.e., 
245), Limit on unique 
user report Ids is 
2147483647 



Copv Report Definition 





■ Name^;:x : : ; ; - ; :-- .-J 


ParameteiriTypei^J 


^Required'* 


a Acceptable^: :; 

rValue^ : ;:£f : ;^' 


CRD 


Request 


Char (3) 


Yes 




USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 


NAME= 


User report 
name 


Char (50) 


Yes 


User report 
name 



Conv Report Definition Acknowledgment 





"Name^;';;./:;:;;::^':.; 


; Parameter J 


ype^j 


^^equired|5 


•^Value : ^;^ : 0,; : : ;: ; 


CRDA 


Response 


Char (4) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 



Update Report Status 





;:P3rameter^v;:j 

^3me3-^ ; V^r-> 


rType^f Viv. :•: 


^Required^i 


iAcpeptebte^alue;^ 


URS 


Reauest 


Char (3) 


Yes 




USERRPTID 

s 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). Limit on 
unique user report 
Ids is 2147483647 
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ACTIVE 


User Active 


Char(1) 


Yes 


0 - for saved/not 
scheduled 

1 - for scheduled 



Update Report Scheduling Acknowledgment 





'PerarneteiS'J.*.' ,f 

:Narney;:.;\.;:;;;-y'::; 


Parametei^Typer | 


: Required;v^ 


/Acceptable^v ;;■ 
rValu^. : ^;^v '"1 


URSA 


Response 


Char (4) 


Yes 




ERROR* 


Error Code 


Char (4) 


Yes 


0 or error 


USERRPTID = 


User Report ID 


Char (10) 


No 


User Report ID 
(i.e., 245). 
Limit on unique 
user report Ids 
is 2147483647 


Get Pick List — Accc 








HParaiflet^ 


IrRequirediS; 


!Accept9Wej£?;.*i 
•Value.:: f •>:v~ * 


GPL 


Request 


Char (3) 


Yes 




PL ACCESS- 


Pick List Type 


Character 


Yes 


PL_ACCESS 


10= 


Inbound/Outboun 
d 


Char(1) 


Yes 


Mnbound, 
O=0utbound, 


PRODUCT* 


Product 


Cnar(1) 


Yes 


T«TollFree,V 
* Vnet, S = 
Vision, C = 
CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char (1) 


Yes 


U = Unpriced, 
P » Priced, 
B = Both 


Get Pick List Acknowledgement — Access _ _ . 


|?|Ulessage-^--' ■ - v"*: 


Parameter^ v 


^ ParameterrType & 


| ' Required - 

i ■*.'■'■'■. ■ : 


^Acceptablefe: -> 
; ; Valuer, 


GPLA 


Response 


Char (4) 


Yes 




ERROR* 


Error Code 


Char (4) 


Yes 


0 or error 


PL_ACCESS= 


Pick List Type 


Character 


Yes 


Access code, 
Description 
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Get Pick List -Fields 



;Message> : \/k : 




parameter^ype^:S 


Required^ 




GPL 


Response 


Char (3) 


Yes 




PL FIELDS 


Pick List Tvoe 


Character 


Yes 


PL_FIELDS 


RPTTMPID= 


Report Template 
ID 


Char (10) 


Yes 




Get Pick List Acknowledgement - Fields ; 




vName;t;^;-''';^v;;;^ 


^paj^^^ypafl 


^Required 


• ; 


GPLA 


Response 


Char (4) 


Yes 




ERROR- 


Error Code 


Char (4) 


Yes 


0 or error 


PL_FIELDS= 


Pick List Type 


Character 


Yes 


FieidID, 
FieldHeader, 
FieldCoIumnHi 
de, FieldSort 


Get Pick List - Duration 




^Paraniet^^C^- 


^Parametiern'ype^ 


lipequired-i 




GPL 


Response 


Char (3) 


Yes 


single or 
Multiple Values 


PL_DU RATION 


Pick List Type 


Character 


Yes 


PL OURATIO 
N 


Get Pick List Acknowledeement - Duration ' 


l;^^;v : ^rsi•i■V"^^v::^:lV^~v.. i ^;.• 


^Parametei^^^ 


i^Param^e^Type;^ 


^Required? 


^qceptahleE^^; 

.:;^VaIue^i : 3^'^ 


GPLA 


Response 


Char (4) 


Yes 


stnaie or 


ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_DURATION= 
example 


Pick List Type 


Character 


Yes 


Duration 
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Get Pick List -Time Zone 



GPL 



j; parameter-'; 



Response 



$ Parameter JVpe'{^5 BequirM#; Acceptable:: 



Char (3) 



Yes 



PL TIMEZONE I Pick List Type I Character 



Yes 



PLJTIMEZONE 



Get Pick List Acknowledgement -Time Zone 



^Parameter; 



Parameter Ty|^ 



GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (41 


Yes 


0 or error 


PL_TIMEZONE= 


Pick List Type 


Character 


Yes 


TimeZoneCode 
. Description 



|MfSsa ; rje^:v; 


iTlitHiHdiJMaHl 


^paramiteMyp^ 


pRequired^ 


;}:yalue:^;vv'^§r:y 


GPL 


Response 


Char (3) 


yes 




PL HIER 


Pick List Type 


Character 


Yes 


PL HIER 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 



Get Pick List Acknowledgement - Billing Hierarchy 



GPLA 


Resoonse 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL HIER- 


Pick List Type 


Character 


Yes 


hierarchy data 



^Message^':.:;--. : :\ 


Parameter^- " " : 


; Par^eterfTy pe 


A Required^ 


^Value^r{; ; ;-^;r'j 


GPL 


Response 


Char (3) 


Yes 




PL GEO 


Pick List Type 


Character 


Yes 


PL GEO 


USERRPTID= 


User Report ID 


Char (10) 


Yes 


User report ID 
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Get Pick List Acknowledgement - Geographical Hierarchy 





{Message^/ ..ju 


Parameter: 


Rarameter^Type 


Required:^ 


Acceptable:^ ^ 

-Value: 1 ;"-:::.-. . 






GPLA 


Response 


Char (4) 


Yes 








ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 






PL GEO 


Pick List Type 


Character 


Yes 


geo data 






Get Pick List - Static Ranee 










1 




^pzjramet^ 


^P^anietef^yp^! 


^Required.ts 


: /Acceptab|e»Valuev^ 


GPL 


Response 


Char (3) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL RANGE 


Pick List Type 


Character 


Yes 


PL_RANGE 


IO= 


Inbound/ 
Outbound 


Char(1) 


Yes 


Mnbound, 
OOutbound, 


PRODUCT= 


Product 


Char(1) 


Yes 


T=Toll Free, V = 
Vnet, S = Vision, C 
= CVNS, H = 
Broadband 


DATACAT= 


Data Category 


Char (1) 


Yes 


U = Unpriced, 
P b Priced, 
B * Both 



Get Pick List Acknowledgment — Static Range 





^Parameter??;; 


'^Paraineteritype^l 


VRequlred^ 


Acceptable 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_RANGE= 


Pick List Type 


Character 


Yes 


range code, 
description 


Get Pick List- Static Usage 


(iVIessageny;-:/:^/;^ 


-■ : Raram^err;^j',;;;^ 


£ Parameter<Type^ 


•^Required Acceptable^- ,r 

.-• .v.".. /'Upvalue!:-;;;: 


GPL 


Response 


Char (3) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


Oor error 


PL USAGE 


Pick List Type 


Character 


Yes 


PL_USAGE 


10= 


Inbound/ 
Outbound 


Char(l) 


Yes 


Mnbound, 
0=Outbound, 
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PRODUCT" 


Product 


Char(1) 


Yes 


T=Toll Free, V 
b v/net, S = - 
Vision, C = 
CVNS. H = 
Broadband 


DATACAT= 


Data Category 


Char(1) 


Yes 


U - Unpriced, 
P » Priced, 
B = Both 



Get Pick List Acknowledgment - Static Usage 







^ Parameter iType^i 


* Required #j 




QPLA 


Response 


Char (4» 


Yes 


0 or error 


ERROR= 

PL_USAGE= 


Error Code 
Pick List Type 


Char (4) 
Character 


Yes 


usage code, 
description 



Get Pick List -Language 



•Message^ 



■Parameter^: 



I- Parameter Type HRequiredv ^Acceptable 



GPL 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (A) 


Yes 


0 or error 


PL LANG= 


Pick List Type 


Character 


Yes 


Lanauaae code 



Get Pick List Acknowledgment -Language 



^Message; 



^ivparaiTieter^ 

^Name-'r^.: 



& Parameter^Ty pe^ 



rt;:RequiredSiSAcceptablev 
rvalue 



GPLA 


Response 


Char (4) 


Yes 




ERROR" 


Error Code 


Char (4) 


Yes 


0 or error 


PL_LANG= 


Pick List Type 


Character 


Yes 


Row 

information to 
follow 



Get Pick List -Currency 



^Message:; / 


' r ";'T7 r paramete?-^'.V'. 
. : ^;-Namevv;.7v'-;\-; 


r pararheterType^ 


iv: Required v 


;^J\cceptabie:>> 


1 GPL 


1 Response 


1 Char (4) 


i Yes 


1 
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ERROR= 1 


Error Code 


Char (4) j 


Yes I 


0 or error 


PL CURR= 


Pick List Type 


Character I 


Yes 1 


Currency code 1 


r.»i pii>u I let Aclcnnwledcment -Currency ■ 




\ Parameter 


/^parameteriTyp 


I Required/^ 


*Apcepteb|eiw;:>rJ 


GPLA 


Response 


Char (4) 


Yes 




ERROR= 


Error Code 


Char (4) 


Yes 


0 or error 


PL_CURR= 


Pick List Type 


Character 


Yes 


Row 

information to 
follow 
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APPENDIX B 



Notify Report Location 







parann?-:';'.-;.'- : T|f 

•Type.* '•• 


flequfred^if 


?Ac^ptabie;Va|ue^ r:; | 


NRL 


Request 


Char (3) 


Yes 




TYPE= 


Designates 
report type, call 
detail tvDe. or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, real-time, 
exception, invoice, 
MIR, CCID. priced 
call detail, outage 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UseriD 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report ID 
{I.e., 2, 44). 


USERRPTID 


User Report ID 


Char (10) 


Yes when 

ft ilfillinn 
III wiling 

server is 
using the 
StarWRS 

Requests 
r 


User Report ID (i.e., 

I imtt on 
unique user report 
Ids is 2147483647 


REQUESTID 

s 


Unique Request 
IU 


Char (10) 


Yes when 

fulfil linn 

server is 

i lei nn thp 

StarWRS 
Report 
Requeste 
r 


Unique request ID 
Qpnt tn fulfilfina 
server in ARD. Limit 
nn rant jest ID is 
2147483647. 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char(1) 


ONLY 
news 


1 - fatal, 2 = major, 3 
= minor, 4 = 
info(default), 5 = no 
alert 


COMPRESS 


Designates 
whether the data 
has been 
compressed 


Char(l) 


Yes 


0 = data not 
compressed, 1 = 
data compressed 


LOC= 


Location 


Char (255) 


Yes 


File Path, name and 
extension 


FSEE= 


Size of 

associated file in 
bvtes 


Char (10) 


Yes 


Limit is 2147483647 
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Parameter: : ; ' : : 
Name^ v ■ 


ParanvKR'.f- 
Typer V' V : £ 


Required-fc 


AcceptableiValue #::h ■ 


REPORTTIT 
LE= 


Report Title 


Char (100) 


Yes when 
fulfilling 
server is 
not using 
the 

StarWRS 
Report 
Requeste 
r 


Report tme to oe 
displayed in Inbox. 


D= 


Inriiratoti 

whether or not 
the fulfilling 
server sorted the 
data on their 


Char (1) 


Yes 


0 = not presorted, 1 
= is presorted. 


ERR™ 


Used to when 
there is no report 
file, but there is 
an informational 
file. 


Char(1) 


No 


ERR-1 or 
ERR=0 


TOTAL* 


Fulfilling server 
totals 


Char 


No 


Sent by fulfilling 
server to indicate 
report totals. 
Column ID and total 
are passed. 


CATEGORY 


Report, call 
detail, or news 


Char(1) 


Yes for 

StarOE. 

Report 

Manager 

will 

determine 
for 

fulfilling 
servers. 


R « Report, D = Call 
Detail, F = News 


Notlfv Renort Location Acknowledcemcnt . 








^Required* 




NRLA 


Response 


Char (4) 


Yes 




ERROR* 


Error Code 


Char (4) 


Yes 


0 or error 


USERID= 


User ID 


Char (20) 


Yes 


User ID 


USERRPTID 


User Report ID 


Char (10) 


Yes 


User Report ID (i.e., 
245). Limit on unique 
user report Ids is 
2147483647 
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ParameterNaej ;|i 


Bill 


Required^ 


Acceptgble^Value: j 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes when 
fulfilling 
server is 
using the 
StarWRS 
Report 
Requeste 
r 


Unique request ID 
sent to fulfilling 
server in ARD. Limit 
on request ID is 
2147483647. 


APPENDIX C 

Add 




vNamB^^ : V;;^ ; ^vi:vf 


:param9.^^;3; 


"Requir^^ccpp^ 


A 


Add reauest 


Chard) 


Yes 


A-aaa 


SEV= 


Servity of 

notification 

messaae 


Char(1) 


No 


1,2, or 3 


CATEGORY 


Item category is 
an report, call 
detail, or news 


Char(1) 


Yes 


R « Report, D = Call 
Detail, F * News 


TYPE= 


Designates 
report type, call 
detail type, or 
news type 


Char (30) 


Yes 


e.g. Broadband, 
priced, unpriced, 
exception, invoice, 
MIR, CCID, priced 
call detail, outaqe 


USERID= 


Designates 
intended 
recipient or 
audience 


Char (20) 


Yes 


Starbucks username 
as assigned in 
StarOE 


RPTID= 


User report ID 


Char (30) 


Reports 
and data 
only 


User report ID (i.e., 
245) 


PRIORITY= 


Standardized 
Network 
Management 
Priority Levels 


Char(1) 


ONLY 
news 


1 = fatal, 2 = major, 3 
» minor, 4 = info 
(default), 5 » no alert 


COMPRESS 


Designates 
whether the data 
has been 
compressed 


Char (1) 


Yes 


0 = data not 
compressed, 

1 = data compressed 
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Para|TiBter^.;vi;.';sHV: 
Name v : ^ 


PararnT?.'..;; :-!^ 


Required^!? 


•Acceptable.Value^^ : • ; ■ 


UNOTIFY- 


Says if user 
snouiu db payeu 
or emailed when 

♦ha Inhnv item ic 

received by the 
Inbox server 


Char(1) 


NO 


u = None taeiauig, i 
= Page, 2 = Email, 3 
- Email and page 


MMADDR 


Override email 
address 


Char(75) 


NO 


Must contain® e.g. 
uss rMvQ' rnui.uu 1 1 1 


MMTEXT 


Override email 

moccflnp tevt 


Char(500) 


NO 




PGT 


Override pager 
JzES 


Char(1) 


No 


As supported by 
Star OE 


PGPIN 


Override pager 

PIN 


Char(8) 


No 


Numerics only 


PGTXT 


Override pager 
text 


Char(240) 
or 

Char(20) 


No 


Alphanumeric pagers 
or 

Numeric papers 


RPTCATEG 
ORY- 


Report category 

(lepufl name; 


Char (50) 


ONLY 
report 


e.g. - Longest Calls 


LOC= 


Location 


Char (255) 


Yes 


Rle Path, name and 
extension 


ENTPID= 


Enterprise ID 


Char (8) 


Yes 


As assigned in 
StarOE 


RQSTDT= 


Report or data 
request 

date/time stamp 


t_>nar ( 


UINL.Y 

report or 
data 


YYYY-MM-DD 

III 1 "IVIIVI 

HHrMM 


FSIZE= 


Size of 

associated file in 
bvtes 


Char (10) 


Yes 


Limit is 2147483647 


PPTTITI F= 
tlr 1 111 Lt— 


Lfoer-defined 
report title, call 
detail request 
name, or news 
short text 


Char (255) 


Yes 


Example: 

"Call Duration 
Summary" 


MSIZE= 


Size of 
associated 
metadata for 
transfer 


Char (10) 


ONLY 
report or 
data 


Limit is 2147483647 


ERRFLAG= 


Fulfilling server 
reported an error 


Char (1) 


No 


0 = no error (default), 

1 = error 
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Add Acknowledgment 





iBaramete^ 
Name - ^: 


*Type^vK ; vf j 






z 


Response 


Char (1) 


Yes 


z 


REQ= 


Request which is 
being 

acknowledqed 


Char(1) 


Yes 


A, D t U F. U 


ERROR= 


Error Code 


Char 


Yes 


0 = no error or error 
code 


INBOXID= 


Inbox ID 


Chard 0) 


No 


Uniauelv assiqned id 



APPENDIX D 



Add Renort Definition 







fparam^*^ 




3 ^ceptable^^e^j 


ARD 


Request 


Char (3) 


Yes 




ENTPID= 


Enterprise ID 


Char (8) 


Yes 


Enterprise ID 


USERID= 


User's ID 


Char (20) 


Yes 


UserlD 


STDRPTID= 


Standard Report 
ID 


Char (10) 


Yes 


Standard Report 
ID (i.e.. 2, 44). 


USERRPTID 


User's Report ID 


Char (10) 


Yes 


User Report ID 
(i.e., 345). Limit 
on unique user 
report IDs is 
2147483647. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes 


Unique Request 
ID. Limit is 
2147483647 


PRODUCT= 


Product 


Char (1) 


Yes 


Vnet = V. CVNS = 
C, Vision = S, Toll 
Free = T, 
Broadband = H 


THRESHOL 
D= 


Record limits 


Delimiter 


Yes 


RECCOUNT, 
RANKING, 
DURATION, ANI 
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RECCOUNT 



Record count 



Char (10) 




Maximum amount 
of records to be 
returned in the 
report results. If no 
threshold is 
received, the 
default reccount 
threshold from the 
report template will 
be passed. 



RANKING= 



TVS Ranking 



Char (3) 



No 



# of call ranks to 
show. If ranking is 
not passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. Range 
is 1-400. 



DURATION* 



TVS Duration 



Char (4) 



No 



# for call duration 
threshold. If 
duration is not 
passed, the 
default value will 
be passed. This is 
a TVS only 
parameter. 
Format is mmss. 
Range is 1-5959. 



ANI= 



TVS ANI 



Char (3) 



No 



# of Items in Most 
Frequent report. If 
ANI is not passed, 
the default value 
will be used. This 
is a TVS only 
parameter. Range 
is 1-400. 



COLUMNS= 



Columns 



Char 



Yes 



These are the 
columns the user 
wants in their 
report. Field Ids 
are to be passed 
here (i.e., 5,17, 
23.441 
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=ILTERS= 


Filters or Criteria 


Delimiter 


Yes for 


Contains multiple 
liters (i.e., 
NDIALED). If 
filters are not 

lC7wt7lVOU| IlllOlO 

from the standard 
report template (if 
any) wilt be stored 
and/or sent with 
request to fulfilling 
server. 


NDIALED= 


Filter 


Char 


Yes for 
TVS nn fnr 

all others 


Number range 


BILUNG= 


Hierarchy 


Char 

i 


Yes for 

UUOi Tea 

for TVS 
Vision and 
VftlET 
biitbound 


Single or multiple 
\/aiijp<* from hillinn 

VQlUww nun i uihii ly 

hierarchy. Must at 
least include the 
Corp ID 


DURRANGE 


Duration Range 


Char 


No 


Single or multiple 
values. 


CARDNO 


Card Number 


Char 


No 


Single or multiple 
values from the 
duration Dick list 


IDISTRANGE 


Inbound Range 


Char 


No 


Single or multiple 
values from the 
Ranqe pick list 


ODISTRANG 
E= 


Outbound Range 


Char 


No 


Single or multiple 
values from the 
Ranqe pick list 


IUSAGE- 


Inbound Usage 


Char 


No 


Single or multiple 
values from the 
Usaae pick list 


OUSAGE= 


Outbound Usage 


Char 


No 


Single or multiple 
values from the 
Usage pick list 


IDAC= 


ID/Account Codes 


^ Char - 


No 


Single or multiple 
values 


GEO= 


Geographical 


Char 


No 


Single or multiple 
values from 
geographical 
hierarchy. 


IACCESS- 


Inbound Access 


Char 


No 


Single or multiple 
values of inbound 
access items 
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OACCESS= 


Outbound Access 


Char 


No 


Single or multiple 
values of 
outbound access 
items 


SORTBY= 


Sort Order 


Char 


Yes 


If sort order is not 
received, sort 
order tor stanaara 
report will be used. 

IT SOU UiUqi la 

passed, it must be 
a column ID and 
ascending (A) or 
descending (D) 
<i.e..lD>. 


TIMEZONE- 


Timezone info. 


Delimiter 


Yes 


LABEL and 
OFFSET. 


LABEL* 


Time description 


Char (3) 


Yes 


Timezone label 
(ie, Mo i ). 


OFFSET- 


GMT offset 


Char (5 


Yes 


User's Time Zone 
in relation to GMT 
e.g. +2, -5. Valid 
range is -12 
through +13. 
Offsets will be in 1 
hour increments 
for the 98.1 
release. 


SCHEDULE* 2 


Report schedule 


Char () 


Yes 


i ne rtepon 
Scheduler will not 
send a request to 
the fulfilling server 
if the report was 
not scheduled. 
A = Adhoc. H = 
Hourly, D = Daily, 
W= Weekly, M = 
Monthly 


START- 


Start report 
schedule 


Char (12) 


Yes 


YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
These can be 
multiple start and 
end dates. Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 
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END* 


End report 
schedule 


Char (12) 


Yes 


YYYYMMDDhhm 
m 

This parameter is 
only used if the 
report is Adhoc. 
There can be 
multiple start and 
end dates. Start 
and end times 
must be passed in 
pairs and will be in 
GMT format. 


TOTALMOD 
E= 


Total mode the 
user selected. 


Char (1) 


Yes for 
ODS, No for 
all other 
fulfilling 
servers. 


0 - None (default), 

1 = Subtotal, 2 = 
Total, 3 « Both. 


SUBTOTCO 
L= 


Subtotal columns 


Char 


Yes if 
TOTALMO 
DE is 1 or 
_3. 


Subtotal column 
IDs. 



Add Report Definition Acknowledgment 



ARDA 


Response 


Char (4) 


Yes 
Yes • 


0 or error 


ERROR= 
USERRPTID 


Error Code 
User Report ID 


Char (4) 
Char (10) 


No 


User Report ID 
(i.e., 245). Limit on 
unique user report 
Ids is 2147483647. 
Please use this 
token whenever 
possible. The only 
time it should not 
be used is when 
the fulfilling server 
cannot parse the 
message at all. 


REQUESTID 


Unique Request 
ID 


Char (10) 


Yes 


Request ID. Limit 
is 2147483647. 
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APPENDIX E 



Report Manager Proxy Codes 



Frror Code. ! t 


Ik-imuIS ^ anv data re q ue i^— 1 


o J 

6050 J 

6101 I 

6102 1 


letransmission on NRLA , . 

general failure . . 

Failure with parser building parameters m 


6103 „ 

*104 


Parameter error - missinp. etc. 

No valid request . ■ 


6105 

6106 

6107 

6108 


Database connectivity error 

Database command error 1 

Report Manager ID error 

Error opening file 


6109/7000 

6110 

611 1 


no records found meeting criteria — . 

SOL cannot connect — — A 

Cannot execute stored procedure „ — 1 


6112 

6113 

6114 

6115 

6116 

6600 

6601 

6602 

6603 _ 

6610 

661 1 

6612 . 

6701 


SQL open cursor 1 

Enterprise ID or user report title empty . 

Required parameters are missing _ , . 

IDs are not correct . — 

FF not correct — 1 

Report title is null . 

Number dialed is null m . 

Stan date is null — — ■ ■ 

End date is null — 

Token is unknown a . ■ 

Empty or incorrect input string - — 1 

Unbalanced brackets % . . 

Required tokens missing — 


6702 

6703 ... 

6704 

6705 


Missing parameter value , . 

Required tag in message has no value. _ J 

Category cannot be empty. 1 

Range tvpe cannot be emptv if sched tvpe neq adhoc. ; ! 


6706 

6707 

6801 

6802 

6803 

6804 

6R05 

6806 

6807 

6808 

6809 

6810 _ 


Enterprise id length is invalid - cnectc conhg.mi tor fcNiriLit.cri 

" Fulfilling server returned a response that appears to be incorrect.; J 

Missing ACTIVE parameter . - 

ACTIVE parameter missing value . . 

Missing CATEGORY parameter . ; . — 

CATEGORY parameter missing value „ — 

Missing COMPRESS parameter . — 

COMPRESS parameter missing value 

Missing DATACAT parameter m 

~~ DATACAT parameter missing value 

~ Missing DATATYPE parameter , 

~ DATATYPE parameter missing value . 
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6820_ 
6821 
6822 
6823 
6824 
6825. 
6826 
6827 
6828 
6829 
6830_ 
683 1_ 
6832 
6833 
6834 



Missing r • ■ 

FULSERVER parameter m issing value 
Missing LOC parameter 
LOC parameter missing value 
Missing NAM E parameter 
NAME parameter missing value 
Missing PAGE parameter 
PAGE parameter missine value 

Missin g PRODU CT parameter 

PRODUCT parameter m issing value 

Missing REPQ RTID narameter 

REPORTTD parameter missing value 

Minin g RPTTM PLID parameter 

RPTTMPLID parameter missing value 
Missing , SCHF "TVPE parameter _ 
SCHEDTYPE parameter missing value 



Missing STDRPTID parameter 

STDRPT1D parametermissing value 

Missing TYPE parameter 

t vpf parameter missing value 
Missing USE * TP parameter 
USERIP parameter miss ing value. 

Missing USERR PTID parameter 

USERRPTID parameter missing value 



Inbox ProxyCodes 



soos 

5100 
5101 



5105. 
5106 



1 '' y^lL' ^BS^g ^^^^ 

-™ } ■- ■>- — * ™ * he added agam - — 



OK 



^ J »■ ^ 

have been encountered. — — — 

mired parameter missing 
R wiliest is invalid or u nknown. 
S Fetch request, the ffle speci fied in the Inbox d atabase cou.d not 

r nTdTotmake an S ™ .nation to the Inbox database,, 
Prrnr occurred tr "T P^eute tneTtored procedure. 
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5108 



5166 



a M„rin P an SOL open cursor ran. 



Error occurred aunng an j ul ^ — — - — . 

Irror occurred trying «o c onstruct the filename lor a Fetch metadata 

SLr Hnboxid ~ ' '""ctt "i«int on update commano. 
TTL missine or invalid on Update 

Category missing on Update. 

InboxlD parameter missin e in Fetch. 

no records tW far deletion by stored procedure 
UserlD parameter missi ne in List. 

Category missing in Lis t. 

UscriD parameter missing in Delete. 



Catepotv parameter invalid in Add 

Tv nc parameter invalid in Add. 

Ent pID+UserlD parameter miss ^ or invalid in Add, 
RptID parameter missine in Add 



m-r— r ra,nMer mis5ing '" Add ■ J . A ,„ 

sVw nnrameter miss ™ when Unotity specified in Add. 
B ptCateeorv (repo rt name) parameter missine in Add. 



Loc paramet er missing in Add — _ 

Re quested date parameter mi ssing in Add 
Fsize parameter missine in Add 

n P <Ti tln parameter miss ing in Add 

M C i~ parameter ra cing in Add tor K-eport grData 

* in Loc parameter does not exist. 

P nmID parameter -^inff when unotifv specified. 
COMP and LOC parameters conflict, e.g. compress indicated but 

extension do es not end with _zi" 

metadata file do es not exist. ■ 

iit ratification et" r-«ed in coniuncl.on with 5171.5172.5174 

Via user or ent er prise ID in use niotification 
Notification level is null 

Unknown notification level 

Invalid constructor call in user notification 

In ilirl — ;l """" & ,n ^rT° tlf ' caI '°il 

■f -^~,c rt „.x, exists in user notification foreman 

■ l yLld not be ser — T ""* mtssine « user notmcauo n 
— 6 — : — . ... u.~;~ rtaffiiitt pmnil/naeine into 



i'" ,w> 1 " ■ | 

> nmm fai i ure ; n trvinc to o btain default email/paging into — 

terror wh- TT " ^ 
-Prmr when attempt- "f m fork a child process in email/paging 
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APPENDIX F 



Get Metadata 



^Message;; 



^parameter Nam^ 



^Required WM c e p ta \*\& 

•"■v. 'V r-i- Value 



Delimiter 
Delimiter 
Name of report 



TotalJnbouncLA 
mount* 



TotaLOutbound^ 
Amount^ 



Total inbound 
amount 



Total outbound 
amount 



Total_Amount= 



Total of inbound 
and outbound 



Char 
Char 
CharOOO) 



Char 



Char 



No 



No 



TotaUnbound_ I Total inbound 
Minutes= I minutes 

total_Outbound_ I Total outbound 
Minutes= I minutes 



Char 



Char 



Char 



TotaLMinutes- Total of inbound 
and outbound 



TotalJnbound_C 
ails= 



TotaLOutbound. 
Calls= 



TotaLCalls= 



No 



No 



NO 



Char 



Total outbound Char 
calls 



Total inbound 
calls 



Total of inbound 
and outbound 



Char 



Char 



No 



No 



No 



Column ID and 
Total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 



Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
Column ID and 
total passed In 
by fulfilling 
server in NRL 
Column ID and 
total passed in 
by fulfilling 
server in NRL 
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Total* 



Description 3 



Report_Level= 



TVS total 



Options- 



Suppji 



Access JType= 
Card_Number= 

JD/Accounting_C 
odes ; 
Number J3iated= 

Range' 
Usage= 

Schedulingjnfor 
mation 

One_Time= 
Or 

Recurring= 



Dates= 



Char 



Char (100) 



Char 



Description of 
report. 



Report level 
selected for this 
report 



Option line 

Supplemental I Char 
Codes selected 
by customer 

Access type 
selected 
Card numbers 
selected by 
customer 
IDACs selected 
by customer 
Number dialed 
Ranges selected 
by customer 
Usages selected 
by customer 
Scheduling line 



Yes if 
TVS, No 
for all 
others 



Yes 



Yes 



Char 
Char 



Char 

Char 
Char 

Char 



No 

No 
No" 

No 



Schedule type 
selected by 
customer 



Start and end 
dates if one time 
report or 
recurring type if 
recurrinc 



Char 



Char 



No 



Yes 



Yes 



If fulfilling 
server is TVS 
insert text 
Totals are 
located at the 
bottom of the 
report." 
Description of 
report 
truncated to 
100 characters 
All Levels, 
Service Group, 
Billing Group. 

etc. 

No values will 
be displayed 
with thi s^ 
List of 

supplemental 
codes if 
selected. 
Dial 1, Card, 
etc. 

List of card 
numbers 

List of IDACs if 
selected. 
800 number(s) 
List of ranges 

List of usages 



No values will 

be displayed 

with this 

If recurring no 

values will be 

displayed with 

this. If one 
time, show the 
multiple start 
and end dates 
Start and end 
dates if one 
time or 
recurring type if 
recurrinc 
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Time_zone= 



Lang= 



Time zone 



Indicates the 
language a user 
picked. 



Char 



Yes 



Char(4) 



No 



Time zone- 
either default 
or overridden 
value (MST) 



Default will be 
American 
English, the 
values are not 
defined 



Curr= 



Indicates the 
language a user 
picked 



Char(4) 



No 



Default will be 
American 
Dollar, the 
values are not 
defined, 



DEFAULT__GRA 
PH MODE= 



Default graph 
mode 



Char (1) 



Yes 



0 - None, 1 = 
Graph, 2 = Plot 



DEFAULT_GRA 
PH_TYPE= 



DEFINE_X_AXIS 



Default graph 
type 



Char(1) 



Yes 



0 « None, 1 = 
Bar, 2 = Line, 3 
= Pie, 4 = Point 



Define default x 
axix . 



Char (1) 



Yes 



0 = No, 1 = Yes 



X_AXIS_COLUM 
N= 



X axis column 



Char 



If 

define_x_ 
axis is 

Yes 



X axis column 
D 



DEFAULT_Y_C 
OLUMN= 



Default Y column 



Char 



No 

"YeT 



List of column 
Ds for y axis 



COLUMNJMSP 
LAY_ORDER= 



Column display 
order 



Char 



List of column 
IDs to display 
in a particular 
order 



COLUMN_STOR 
ED ORDER 



Column stored 
order 



Char 



Yes 



Order columns 
are in default 
template 



SORT_ALLOWE 



Sort allowed on 
viewer 



Ghar(1) 



Yes 
"YeT 



0 * No, 1 = Yes 



PRESORTED 



Presorted by 
fulfilling server 



Char(1) 



0 = No. 1 = Yes 



TOTALMODE= 



Total mode 



Char(l) 



Yes 



0 = None, 1 = 
subtotal, 2 = 
total. 3 « both 
List of column 



SUBTOTCOL= 



Subtotal columns 



Char 



Yes if 
TOTALM 
OD is 1 or 

3 



IDs 



SELECTED_SE 
CTION* 



Pick list on a 
certain column 



Char (1) 



Yes 



0 = No, 1 = 
Yes. If Yes, 
SUBTOTCOL 
must contain 
information 



METACOLUMN= 



Delimiter 
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META_COLUMN | Column ID 

JD= ^ 

COLUMN_LABb [ Column header 

L= 

"DATATYPE= I Datatype 



DECIMAL= 
HIDEABLE= 



Decimal point 

Column can be 
hidden on viewer 



GRAPHABLE= 

WIDTH- 
CALCULATE 5 



CALCULATED 
XPRESSION* 



Column can be 
graphed on 
viewer 
Default column 
display width 
Determines if 
viewer should 
calculate the 
column 
Calculation 
expression 



Char 
Char 
Char 



Yes 
"Yes* 
Yes 



Char 



Char(1) 



Char (1) 

Char 
ChaT(1) 

Char 



Yes 



Column ID 
Column header 



Indicates the 
way the data is 
received from 
fulfilling server. 
S « string, C « 
character, I = 
integer, N = 
number, D = 
double, L = 
long 



If 

CALCULA 
TE is Yes 



Number of 
decimal points 

0 • No, 1 ~ Yes 



0 = No, 1 = Yes 



Default column 
dis play width 
0 = No, 1 = Yes 



Calculation 
expression 
using column 
IDs. 
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APPENDIX G 





;Parameteri «i:Raram: ' v j 
Name- i;Type: • •! 




VAcceptableiValuet: ../, 


D 


Request 


Chard) 


Yes 


u * ueieie 


INBOXID= 


Unique Inbox ID 


Char(1 0) 


Yes 


ID assigned by Inbox 
to uniquely identify 
the item to be 
deleted 



Delete Acknowledgment 



^paramet^i 

?3$kNaniB&f«w?. ; 



z 


Response 


Char (1) 


Yes 


Z 


REQ= 


Request which is 
being 

acknowledged 


Char(l) 


Yes 


D 


ERROR* 


Error Code 


Char(4) 


Yes 


0 = no error, else 
error code 


ifeUte All Items 












^Acceptab|e^ajufe;iv?| 


D 

IISERID* 


Request 

User ID 


Chard) 
Char (20) 


Yes 
"Yes" 


D = Delete 
User ID 


ENTPID= 


Enterprise ID 

edoment 


Char (8) 


Yes 


Enterprise ID 




^pararnr 7 -!;";- 
,?Type^:i;^;v> 


j^Require^^ 




z 


Response 


Chard) 


Yes 




REQ= 


Request which is 
being 

acknowledged 


Char(1) 


Yes 


D 


ERROR= 


Error Code 


Char(4) . 


Yes 


0 * no error, else 
error code 
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List 





Name:*--' - : '-i'v 


Raramnrii-;:-';* * 
Tvoe:^ 


Requimi^^ 


Acceptable .Valuer 1 1 








Chard) 


Yes 
Yes 


L = List 
Enterorise ID 




L 


Request 




ENTPID= 
USERID= 


Enterprise ID 
User ID owning 
item 


Char (8) 
Char (20) 


Yes 


As assigned by 
StarOE 




CATEGORY 


Inbox item 
category to 
return 


Char (1) 


Yes 


R = Report, D -Call 
Detail, F = News 




INBOXID- 


Latest Inbox ID 
in Inbox 


Char (25) 


No 


Inbox Id to return 
entries later than 
















^Paramir-"i^;i 
Type^ Vuu 




^Acceptable iValiu^ $ 




z 


Response 


Chard) 


res 






REQ= 


Request which is 
being 

acknowledged 


Char(1) 


Yes 


L 




ERROR- 


Error Code 


Char(4) 


Yes 


0 — no error, else 
error code 




INBOXID 


Latest Inbox ID 
requested 


Char (25) 


No 


Supplied Inbox ID on 
request 




TTL= 


Time to Live 


Char (3) 


No 


"Time to live" in days 
-before 

automatically purged 
fromdbf. Default is 
45 davs. 




<data> 


data 


Char 


No 


1 see format below 
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:;Paranieter^^-- : ;;| 
vNamevi ,:•>.'."■■! 


;Param^;;V:t 
;Typet>: '"• -•! 


; Required^ 


■.Acceptable^Value^ ; r 


F 

INBOXID= 


ID assigned by 
Inbox to uniquely 
identify the item 
to be located 


Char 


Yes 







Pararrieter^^ 

Name^^; : ^^ :; ;'^;>!-- 


Raraim^oy^' 5; 


Bequired:^ 


Acceptable;Value - ■ 


u 


Operation flag- 
update request 


unarti) 


TOO 

Yes 


Enterprise ID 


ENTPID= 
USERID= 


Enterprise ID 
User ID owning 
item 


Char (8) 
Char (20) 


Yes 


As assigned by 
StarOE 


INBOXID= 


Inbox unique ID 


Char () 


Yes 


ID assigned by Inbox 
to uniquely identify 
the item to be 
located 


TTL= 
ACK= 


Time to Live 

Acknowledge 
item 


Char (3) 
Char(l) 


No 
"No 


Time to live" in days 
-before 

automatically purged 
fromdbf. Default is 

45 days. 

0« not 

acknowledged 
1 = acknowledge 
item (default) 



iTpfifltc Acknowledgment 



Request 



Chard) 



Yes 



z_ 
u 



z 

REQ= 



Request which is 
being 

acknowledged 



Char(1) 



Yes 



ERROR= 



Error Code 



Long 



Yes 



0 — no error, else 
error code 
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APPENDIX II 



AccossJTypc 

Column Nnmo 
accossjypojtoy 


Typo 

smallint 


Nulls 

no 


Definition 

Unique gonoralod 
koy 


Range or example 


tjniquc_accoss_valu 
c 


char(20) 


yos 


Unique slrino value 
of access typo 
{mandated by use of 
At DeclsionSuito) 


DIAL- 10 


lovcl 


smallint 


IIU 


Mochnnlsm to 
(constrain parenl. 
child, attribute 
relationships & 
provide lor littering 
(mandatod by use of 
Al DocislonSuile) 




accoss_codo 


char(2) 


no 


Indicator for n 
particular accoss 
method 


1.2.3,4.5, G. 7. 0. 
9, 10, A, D, C. D. 


acccss_valuc 


char(-tO) 


yes 


String value ol 
Accoss 


SHARED. DIAL- 
1.CARD. 
DEDICATED 
ACCESS. 000 
REMOTE ACCESS, 

DIRECT DIAL FAX 
CALLS. 

STORE/FORWARD 
FAX CALL 
CELLULAR, LOCAL. 
000 BUSINESS 
LINE. 000 WATTS 
LINE. 000 

DEDICATED LINE or 
000 IMTERSWITC1 1 
NETWORK CALL . 
REDIRECT/DTO 1 


avjong^dosc 


cliar(50) 


yos 


a long lexiuui 
description of tho 
access typo 


hint ftirrAMllv 
populated 


Lovcl 


Smallint 


no 


Mechanism to 
(constrain pnront, 
child, niirtoute 
relationships & 
provide for filtering 
(mandated by uso of 
Al DeclsionSuito) 


l.o access vaoulltiG 


ln_out 


char( 1 ) 


no 


Indicator specifying 
II 

Call was inbound or 
outbound 


1 orO 
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Column Homo 


Typo 


Hulls 


Definition 


nnrtfle or example 
vnluo 


billlnn.corp.koy 


sortal 


no 


Gonornicd koy 




onip_corp - _blli_scrv 
_cornbo 


chQf(35) 


no 


noneallnallon of 
entorprisojd, 
corporatojd, 
bllfino Jd & 
sorvico Joe Jd 


0000000 1_9999999 
9_YO0O0OOl_N0OOO 
001 


lovol 


smnllint 


no 


Mochanlsm to 
(constrain parent. 
cliQd, atlrlhuto 
rolatlonships & 
provldo for filtorino 
(mandated by use of 
Al DocislonStiltc) 




oniorprisajd 


chnr(0) 


no 


MCI Idontifior of a 
orotiplno of Corp Ids 


00O00001 


corpornlojcj 


char(0) 


no 


JUtPI Irlnnlifinr Inr 

Customor 




billinoJd 


chor<0) 


yos 


MCI idonlifior for 
Invntrn rocinlnnt 


Y000000I 


sorvico Joc.ld 


char(0) 


yes 


MCI Idonlifior tor 
physical location of 
a subscribed sorvicn 


N0000001 


ontorprlso_namo 


cliar(30) 


yos 


Custom or namo 
associated with 
cniorpri50_KJ 




corporale_namc 


chnr(30) 


yos 


Customor namo 
associated with 
corpjd 




billinfl.namo 


char(30) 


yos 


Customor namo 
associated wilh 
billinoJd 




sorv_loc_namo 


char(30) 


yes 


Customor namo 
•assoclatod with 
sorvico Joc_kl 




sorv_corp_nnmo 


char(iO) 


yes 


Company 'owning* 
Iho customor (l.e 
MCI) 




Oxx 


Column Namo 


Typo 


Nulls 


Do'lnillon 


Rango or cxamplo 
value 


flxxjtny 


Surlnl 


no 


Generated ltey 




flxx 


char(lO) 


no 


000 or 000 number 
dialed for Inbound 
services 


00072<t3524 
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CDlumii Mamo 1 


Typo 


Nulls 


Definition 


nango or oxnmpie 
value 


lovci 


Smalltnt 


no 


Mechanism to 
(constrain parent, 
child, attributo 
relationships & 
provide for filloring 
(mandated by use of 
Al DccfslonSuilo) 




CnrtI 






Column Mamo 


Typo 


Mulls 


Dollnlllon 


Flanfjo or example 
value 


cardjcoy 


serial 


no 


Generated koy 




card .number 


char(tG) 


no 


000 or 000 number 
dialed lor Inbound 
sorvlcos 


0007243624 


lovci 


smallinl 


no 


Mechanism to 
(constrain parent, 
child, attributo 
relationships & 
provldo for filtering 
(mandated by uso of 
Al OocislonStilto) 




starcard_codo 


char(l) 


yos 


Idcnltiflos as star 
card & typo of star 
card foaturo 




Translation 


char(30) 


yes 


Customer dofinod 
tmnslatlon of 
cnrd_numbor (or 
reporting purposes 




Idacc 




Column Nuiuo 


Typo 


Nulls 


Doflnlllon 


Range or example 
value 


ldncc_l<oy 


Integer 


no 


Gonoratod Icey 




ldncc_dcscription 


charQ 


no 


A uniquo Idcodo or 
AccountinQ code 


Concatenated 
corpjd idacc 
combination 


lovet 




no 


Mochanism to 
(constrain paront. 
child, aliribulo 
relationships & 
provldo for filloring 
(manclaiod by uso of 
Al DaclslonSulto) 




Idacc 


char(1G) 


yes 


Id/Accounting code 


MARKETING 



-132- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCI7US98/20148 



Dnta_Stroam 
Column Namo 


Typo 


Nulls 


Definition 


rinnnn nr nvrttnnlft 

|IIU1\JU \JI U*«I1II|)IU 

vnhio 


lino .cpocd 


chnr(5) 


no 


A uniquo vnluo lor 
lino spocd 




lOVOl 


smallint 


no 


Mechanism to 
(constrain paronl. 
child, attribute 
relationships & 
provide for filtering 
(mandated by uso of 
Al DeclslonStillc) 




Pny_phono 






Column Hamo 


Typo 


Nulls 


Definition 


rtango or example 
. vnluo 


pay_phono_cd 


Char(1) 


no 


Indicator specifying 
a payphono call 


P or blank 


pay_phono_descrlpl 
ion 


Char(O) 


no 


A unique vatuo for 
lino speed 


Payphono or blanks 


level 


Smallint 


no 


Mechanism to 
(constrain paronl, 
child, attribute 
relationships & 
provldo for filtering 
(mandated by uso of 
Al DocisionSulto) 




GMT A t.S T 






Column Nanio 


Typo 


Nulls 


Doflnltlnn 


Rango or example 
value 


limo_koy 


soriai 


no 


Uniquo gonoralod 
Uoy 


1 


iimo_ciescription 


char(30) 


no 


A uniquo 

description of a tlmo 
value 


Thursday. January 
1, 1090 00;01 


curronMnd 


char(t) 


no 


Denotes if data for 
tlmo period has 
been loaded In the 
factlabto(s) 


Y or N 


Rosolution 


char(l2) 


no 


Hierarchy levol with 
In tho tlmo dlmoslon 


Year, month, week, 
day of month, day 
of wook, hour, 
mlnuto 


Soquonco 


smallint 


no 


Denotes relative 
ordor within 
ro soil Ion 


A numeral value 
beginning @ 1 


soqjn.ycar 


smallint 


no 


Denotes rnlaltvo 
order within yonr 




Yoar 


char(5) 


no 


A year 


t.o.1990 


Month 


chor(9) no 


A month 


I.e. January 
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niAT A LST . , ■ 






Column linmo 


Tvnc 


LI. all** 

Nulla 


Definition 


Range or example 
value 




Woolc 


cnmlllnl 


no 


*n ( ii k*tnn\f nt n vnnf 


1 llmi 54 




Raio 


ciinr(l) 


no 


nii/lslon of week 

UIVI3IUII Ml t*w*#i» 

Into periods (or 
which differing 
larrifed rates may 
bo applied 


1,2. 3. 4, 7,0or<J 






smalllnl 


No 


Tho numorlc dny of 
iho month 


I.e. t 




day_ol_wceli 


char(9) 


No 


Tho string value lor 
a day 


Thursday 




Hour 


sarnlllnt 


No 


24 hour clock lima 


00 thai 23 




Minulo 


smallint 


No 


Tho numeric minute 
vnluo 


00 thru 59 




datelime 


dato yonr to minute 


No 


Date time stamp 






Product 
















Pnlnrnt\ I.I n rryt\ 


Tvno 


Nulla 


Doflnlllon 


nango or example 
vnluo 


proclucU<oy 


char(4) 


no 


Indicator specifying 
Invoicing systom 


0010, OOt 1,0015 Or 
0010 


product_nanio 


char(30) 


no 


Invoicing systom 


Vnol 


lovel 


smallint 


no 


Mechanism to 
(constrain parent, 
child, attributo 
relationships & 
provide for filtering 
(mandalod by uso of 
A! DoclsionSuitc) 




producuabv 


ehar(i) 


no 


Abrogation of 
produst codo 


V,S, TorC 


. r\r\n Hnn & Term Goo & Report Geo 


Column Name 


Typo 


Nulls 


Doflnltlnn 


Rnngo or cxamplo 
valuo 


goo_koy 


smnllinl 


no 


Gonoratndjcoy 






goo_doscrlplion 


char( ) 


no 


Unlquo description 




lovol 


smallint 


no 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provide for filtering 
(mandated by uso of 
Al DcclslonSullo) 


I 


couniry_cd 


char(3) 


yos 


Indicator specifying 
a country 


001 for USA 
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«. TArm nnn&ncnnrt Geo 






Column Mnmo 


Typo 


Nulls 


Definition 


Rnnnc or oxnmplo 

VUllIu 


npn 


char(3) 


yos 


Geographical 

■ « t * 1 _ L l--.it. 

division In tho North 
Amorica Numbering 
Plan Aroa 


719 for Soulhorn 
LtOioracio 


nxK 


charf3t 

wl till I %J f 


yes 


Throe digit location 
codo 0/ tho seven- 
digit notwork 
number used In 
dialing. N is any digit 
between 2 & 0 and 
X Is any digit 
between 0 & 9 


535 


rouling_cd 


smallint 


Yes 


Used by somo 
countries to 
subdivldo tholr 
country codo 


1232 for Dclfasi 


Irunlt 


char(4) 


yos 


MCI switch trunk 
group 




switch 


chnr(4) 


yos 


MCI switch 




clly__nnmo 


cliar(10) 


yes 


A city's namo 




stalo_cd 


char(2) 


yos 


Two character codo 
for slato 


CO 


country namo 


char<30) 


yos 


A country's name 





Column Namo 


Typo 


Nulls 


Dollnltlon 


Range or cxnmplo 
value 


usagojtoy 


Smnlllnl 


no 


Gonoraled Uoy 




uso_cd 


Char(l) 


No 


Indicator of 
geographic 
attributes of a call 
would which 
dotormlno Iho type 
of tariff that should 
applied 


1,2,3,4. 5. G, or 7 


Uso_dosc 


Char(20) 


No 


Uniquo description 
of uso cd 


INTERSTATE, 

INTRASTATE, 

INTERNATIONAL. 

INTRASTATE- 

iMTRALATA, 

INTRACITY-IMTL, 

INNTRALATA, 000 

INTL-INBOUMD 
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USDflO 




Column Morno 
Subusaoo 



SiitJusago close 



Char(1) 



Char(20) 



Lovot 



Smnlltnt 



No 



No 



Indicator of 
goographlc 
characteristics 
which when 
comblnad with n 
usago codo can 
further afloct tho 
typo of tariffs 
applied 



Untqtio doscriplion 
of subusaoo 



Mechanism to 
(constrain paront, 
child, attribute 
relationships & 
provldo for filtering 
(mandated by use of 
Al DccisionSuite) 



1,2.3. '1. 5.G.7.9. 
A.B.C.GorL 



CANADIAN, 

TERRITORIAL. 

MEXICO-DOW. 

OMNET- 

OMNICALL. 

OPPNET- 

OMNICALL. 

MEXICO- 

BOURDER, 

CARRIQEAN. 

PROMO. ALASKA, 

HAWAII, PUERTO 

RICO. VIRGIN 

ISLANDS, GUAM. 

LOCALNET 



Column Matno 


Type 


Nulls 


Doflnltlon 


Range or cxnmplo 
vnlno 


EVS_Pro<hict_cd 


Char(3) 


No 


Indlcntor cpoclfying 
special fonturos ol 
Inbound calls 
utilizing an 
EVS(Enhanccd 
Voice Services) 
product 


30.31.32. 33, 3<l. 
35. 3G. 37. 30.39, 
40, A tor blank 


EVS_producLdosc 


Chai(20) 


no 


Unique description 
of EVS.prodticL.cd 




Love! 


smaillnt 


no 


Mechanism to 
(constrain paront, 
child, attribute 
relationships & 
provldo for filtering 
(mandated by uso of 
Al DccisionSuito) 





-1 36- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US9S720148 



Olrcctoryjxsslst 
Column Homo . 


Tyno 


Nulla 


Definition 


nanrjo or example 

Villi 10 

YorN 


Directory assist 


CUar(1) 


No • 


Ind spoclfylng If call 
was directory 
assistance 




Dir_nssisLdesc 


Char(20) 


No 


Unlquo doscription 
of 

Dlroctory_nssist 


DIRECTORY 
ASSIST OR NOT 
DIR ASSIST 


Lovcl 


Smnllint 


No 


Mechanism to 
(constrain paront. 
child, nttribtilo 
relationships & 
provido lor fiHoring 
(mandated by use of 
Al DcclslonSiillo) ; , 





RnnflO 

Column Homo 


Typo 


Nulla 


Doflnlllon 


Range or example 
vnluc 


Range 


Char(1) 


No 


Indicator spocifyinrj 
band for distance 
sensitivo pricing 


1,2, 3,4,5,0,7,0 
or 9 


Rango_dosc 


Char(20) 
Smalllnl 


No 
No 


Unlquo description 
of Ranpo 

Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provido (or filtering 
(mandated by use of 
Al DncisionSuito) 




Level 


ncn 




Column Memo 


Typo 


Nulls 


DoflnlH^n 


nanrjo or oxampio 
valuo 


ncr jnd , 


char(1) 


no 


Nolworic Call 
Redlroct Indicator 
spocillos If call was 
redirect because 
terminating switch Is 
blocking 


Blank. 1,2,3.4,5, 
A, D, 


ncrjnd.dosc 


char(20) 


no 


Unlquo description 
ol ncr Jnrl 


NOW MCR/DTO, 
HOP1.HOP2. 
HOP3. HOP4. 
HOPS. 

INTERSWITP.il 
DTO OR 
IMTRASWITCII 
DTO 
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Column Mmtio 1 


Tvoo 


Mulls 


Definition 


rtantjo or oxnmplo 
value 


Level ! 

i 


smallinl ' 


! 

( 
1 

1 

1 

4 


vtochnnlsm to 
constrain paront. 

Otlfrf nllrlhlltO 

■olallonshfps & 
irovldo for filtering 
mandated by uso of 
M DorislonSuHe) | 




Cell nhono 


Type | 


Nuiln j 


Doflnltlon 1 


Rango or oxamptc 
voltte 


Column Wamo 




ccll_phono_cd 


Char(1) 


no 


Idontillos cnllas 
collular & type of 
collttlar call 


h.r.r.f, i.2.3. 

A, 5 or G 


cclLphono_dosc 


Char(20) 


no 


Uniquo doscriptlon 
of colLphonojdosc 


HOME, ROAMED 
CALL. 

FORWARDED 
CALL, AtnTIME, 
TOLL, 

ROAMERAIR, 
ROAMER TOLL 
ROAMERDAILY 

surcharge on 

LANDLINE 
TERMINATION 


lovol 


Smalllnt 


no 


Mechanism to 
(constrain paront. 
child, attrthuto 
relationships & 
provklo (or filtering 
(mnndatod by uso 

f\l At r\nri*:lnnRiiit(*\ 




V05 








Column Homo 


Typo 


Mulls 


Doflnltlon 


Rango or example 
value 


VUI» nuy 

vos_cd 


cmnlUnt 
char(1) 


no 
no 


Volco Oporalor 
Sorvicos Indicator 


P t S. E or blank 


vos_cd_dosc 


ch«v(20) 


no 


Uniquo doscrlption 
of vos.cd 


PER TO PER, STN 
TO STN. ECR 
2000F OR NOT 
OPSVC 


vos_clomil 


char( 1) 


no 


Additional aittibutos 
of Votco Opcrnior 
Services call 


A.-R, S. I3.N.O. C. 
D.P.OAG 


vt>r._tinniiLdosc 


char(20) 


no 


Uniquo description 
of 

Vos dolMl 
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vos 

Column Homo 


Typo 


Nulls 


Doflnlllon 


riiittrm nr f*vrtM1l\ln 

riuiiiju or i5A»iiu|jiu 

voluo 


Lovol 


smalllnt 


no 


Mechanism to 
(constrain parent, 
child, altributo 
relationships & 
provido for fillorino 
(mandated by uso of 
Al DoclslonSulto) 




Conl_cnll 






Column Nnmc 


Typo 1 


Mulls I Definition 


rtango or example 
valuo 


conf_cnll_ld 


char( 1) 


no 






conLcnILtiosc 


char(20) 


no 


Unique description 
of 




level 


smallinl 


no 


Mochanlsm to 
(constrain paront. 
child, attrlbtilo 
relationships & 
provido (or fillorinrj 
(mandated by uso of 
Al DoclslonSulto) 




Tablo7-1 Cro3a_cor 


T> ■ ^ 


Column Mama 


Typo 


Nulla 


Dotlnltion 


Flnnrjo or cxnmpto 
value 


cross_corpJnd 


char(1) 


no 






cross _corp_.de sc 


char(20) 


no 






lovcl 


smallinl 


no 


Mechanism to 
(constrain parent, 
child, ntlributo 
relationships & 
provido for fillorinrj 
(mandated by uso of 
Al DoclslonSulto) 




Curroncv 


Column flamo 


Typo 


Mulls 


Doflnlllon 


nana 0 or cxnmplo 
value 


currancy_cd 


char(3) 


no 


Specifics tho typo of 
currency the call Is 
Invoiced In 


USA 


curroncy_dosc 


char{20) 


no 


Unlquo description 
of curoncy_cd 
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Currency 

Column No mo 


Typo 


Nulls 


rinflnlllnn 


Rannc or example 
valuo 


level 


smallini 


no • 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provldo for lillorino 
(manriatod by use of 
Al OeclslonStiito) 




MCT 






Column Homo 


Typo 


riuiis 


Doflnlllon 


Range or oxomplo 
value 




char( ) 


no 


Network Call 
Trnnslor 




ncv_uusc 




no 


Unlqito description 
of 

NdJd 




IUVUI 


smallini 


no 


Mechanism to 
(constrain parent, 
child, attribute 
relationships & 
provide for filtering 
(mandated by uso of 
Al DoctslonSulto) 




Accoaa_Torm 




Column riamo 


Type 


Nulls 


OeflnltKin 


flnnno or oxnmrjlo 


axsjorm_cd 


char(2) 


no 


Indicator specifying 

Elinor sharod or 
dodlcntod 


11, 12, 21 or 22 


accGss_torin_valuo 


char(4) 


yos 


Unique suing vnluo 
of access type 
(mandated by uso or 
At DoclsionSulto) 


S->S, S->D, D->S or 
D->D 


lovot 


Smallini 


no 


.Mechanism to 
(constrain paront, 
child, attributo 
relationships A 
provldo for filler Ing 
(mandated by use or 
Al DccisionSuito) 




Durallon^Rango 




Column Mnmo 


Typo 


Nulls 


Dotinllton 


Rnngo or nxamplo 


Low_ond 


Doclmal(7 a 1) 


no 


Tho low ond of a 
range of duration 
values 


0.0 
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D uration Jlango 
Column Maino 



High_cnd 



Rango_Valtm 



tovol 



Typo 



Docimal(7.1) 



Char(20) 



smallini 



Nulls 


Dofinillon 


Rango or oxamplo 


no 


Tho fov; and of a 
rango of duration 
values 


0.1 




Unique string voluo 


0.0 to 0.1 


no 


Mechanism to 
(constrain pnront, 
child, altributo 
relationships A 
prnvldo (or filtortng 
(mandated by uso of 
Al DoclslonSullo) 





AmounLRango 

Column Homo 
Lov/_ond 


Typo 
Money (7, 2) 


Mulls 

no 


Dolinltlon 

Tho low ond ol a 
rango of amount 
values 


Rango or oxamplo 
0.00 


Minh nnd 


Monoy(7,2) 


no 


The lov/ ond of a 
rango of amount 
values 

Uniquo string value 


0.10 

0.00 to 0.10 


Rango_Vnluo 


Chnr(20) 
smallini 


no 


Mochnnlsm to 
(constrain paront, 
child, attribute 
relationships & 
provide for filioring 
(mandated by uso of 
Al DoclslonSullo) 




pcrspocllvo_baso 




Column Nnmo 


Typo 


tlulls 


Doflnltlnn 


rtnngo or exnmplo 
J value 


hilllng_corp_koy 


inlegor 


no 


Foreign koy to 
DIIIIng_com tablo 




gmU<oy 


Integer 


no 


Forolgn koy to GMT 
table 




Istjtoy 


Intogor 


no 


Forolgn koy to LST 
tablo 




product _koy 


char(3) 


no 


Forolgn koy to 
Sorvlce tablo 




acccssjypoJ<oy 


smallini 


no 


Foreign key to 
Access tablo 




orig.goojioy 


Inlegor 


no 


Foricgn J<oy Into 
Ortg_geo tablo 




fopofLrjoo_koy 


Integer 


no 


Forlognjtoy Into 
reporLgoo tablo 




torm_geoJcoy 


Intogcr 


no 


Forlegnjcoy Into 
lerm_gco tablo 
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porspocllv/o_hnso 
Column Homo 




Nulls 


DollnlHnn 


Ranrjo or example 
value 




Inl nnn r 


no 


Foreign koy lo Oxx 
tnblo 




ICluilC__KOy 


Intcgor 


no 


Forolgn koy lo Idacc 
tnblo 




r* i rrl 1< I* v 


Inlegor 


no 


Forolon Uoy lo card 
tablo 




vos key 


intcgor 


no 


Forolon key lo vos 
table 




■ ictnA l(fw 


Intogor 


no 


Forolon Icoy to 
usage table 




pny_phono_cd 


char(1) 


no 


Forolon koy lo 
payphono tablo 




llno_spood 


char(5) 


no 


A unique valuo for 
lino spood 




dialcdjiumbor 


char(tO) 


yos 


Numbor dialed at 
point of origination 


fl0072<t3G2<t 


tcrm_numbor 


char( 10) 


yes 


Numbor whoro call 
lorminated 


2124706703 


orlg_nurnbor 


diar(tO) 


yes 


Numbor whoro call 
oriolnnted 


7195355100 


fopoiLnumbor 


char( 10) 


yes 


Numbor which vvill 
oppoar on report call 


7195355100 


evs_prodiJcl_cd 


char(3) 


yos 


Indicator specifying 
spoclal foaturos ol 
Inbound calls 

■ ilillTlnn .in PVR 

(Enhanced Volco 
Sorvicos) product 


30, 31, 32, 33, 34, 
35, 3G, 37. 30.39. 
40 or A 1 


nricinn method 


char(l) 


yos 


Indicator spocilyino 
pricing method of 
special features of 
inbound calls 


Y. D. C. B 

1 


productjimo 


daloilmo hour to 
sond 


yos 


Indontifios limo I ho 
usarjo of EVS 
(Enhanced Voico 
Sorvices) producl 
began 




dircclory_asslsl 


char( 1) 


yes 


Indicator specifying 
if tail was directory 
assistance 


Y or N 


range 


char(t) 


yos 


Indicator specifying 
bar. J lor dtstnnco 
sensitive pricing 


1.2. 3. 1. 5. G. 7.0 
or 0 
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porspcctlvo base 
Column Hnmo 


Typo 


NuIId 


Ooflhlllon 


. Ranqe or example 
Value 


ncrjnd 


cl»nr(l) 


yos 


Nolwortc Cnll 
Rodiroct Indicator 
spocifios If call was 
rodiroct becauso 
lormlnatlno switch Is 
blocking 


•* o i a i a n 


ccll_phono_cd 


char(1) 


yas 


Idontlfios call as 
cellular & typo of 
cellular cnll 


R. I I or F 


conLcallJd 


char(1) 


yes 


Indicator specifying 
typo of conference 
call 


a, n, S t D, N, 0. C. 
D, P. Q or E 


cross_corpjnd 


char(l) 


yes 


Indicator specifying 
If the Oxx number 
terminated nt a 
corpjd that will bo 
Invoiced for tho cnll 
but doos not own 
tho Oxx number 


O.TorL 


non_cross_:corpjd 


char(B) 


yos 


Corp Id of Customer 
own! no an Oxx 
number but which 
will not bo Invoiced 
for tho call 


9911111 1 


enhanco_calLfto 


chor(1) 


yes 


Indicator specifying • 
the typo of 
Enhanced Call 
Routing Foahiro or 
Annsv/ornot foaturo 




ruaiiimo.ani 


char(l) 


yes 


Indicator specifying 
Real Timo 
Automated 
Numbering 
Indicator 




ncUd 


char( ) 




Indicator which 
groups logs of a 
Notwork Call 
Transfor (NCT) call 




nci_callJog 


char(1 1 




Tho leg of a 
Nolwork Call 
Transfor (NCT) call 


1,2 or 3 


duration 


docimal(7,i) 


yes 


Call timo in minutes 
of a call 


0 thru 9399909.9 


curroncy_cd 


char(3) 


yes 


Indicator specifying 
the typo ol currency 
used to price tho cnll 


I.e. USA 


amount 


monoy(7,2) 


yos 


Prico of call 
Inclusive of alt 
appllcablo 
surcharges 


0 thru 9999999.99 
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Column Uomo 


Tvoo 


Nulls 


Oaflnli'on 


nanqo or example 
vahio 


nosiircharoo_amt 


monoyf7,2) 


yos 


Prico of call 
Inclusive of 
discounts but 
oxciudlno 

surcharges & laxos 


0 Ihm 0999099.90 


lax 


monoy(7,2) 


yos 


Tax applied to call 


0 thm 0999999.99 


ncr_surchargo 


monoy(7,2) 


yos 


Amount of 
surcharge applied to 
NCR call 


0 thru 0999099.99 


IntLsurchargo 


monoy(7,2) 


yos 


Amount of 
surcharQo applied to 
r.nll If ll Is 

IfClll II 11 Id 

tntomatlonal 


0 thru 9999909.99 


roaltiino_anLsurclia 
rQO 


moncy(7,2\-. 


yos 


Amount of 
surchargo applied 
for roalllmo on! 


0 thm 9999900.99 


paypliona_swrcharg 

0 


monoy(7,2) 


yos 


Amount of 
surchorrjo oppliod 
for a call originating 
at a payphono 


0 thru 0909999.99 


producL-durallon 


doclmal(7.1) 


yos 


Duration of Toll Froo 
call on special 

nlnlfnrmn /I n CV/C\ 

piaiionns (i*o. cvo) 


0 Ihm 9999090.9 


producLusarjo 


dccimal(7,2) 


yos 


Prico of Toll Froo 
call Incurred duo to 
special platforms 
(l.o. EVS) 


0 Ihm 9099009.99 


axs-lcrm-ind 


char(2) 


yos 


Access & 
termination 
indicator, speciifes If 
call was shared or 
dedicated 


It. 12, 21 or 22 


bilLporiod 


smatllnt 


no 


Tho poriod tho call 
Is Invoiced In 


0197 


axsjofm.cd 


char(2) 


no 


Indicator specifying 

Either shared or 
dodtcaled 


11, 12 ( 21 or 22 
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APPENDIX I 

The data types are as follows: 
char » character 
varchar » character 
•integer » integer 
smallint ■ integer 



Column ID Table 
Standard column, 
columnid 

( 

colid integer, 37 

ia_name varchar (4 0) , Total Arat 

ia_jndLjf»anie varchar (40), C33C;:Total Amt 

rptmgr_name varchar (40), Tot Amt 

forma t_ columns chard), N 

rpttype chard), B 

fact_dim_£lag chard), F 

subtotalflag chard) , Y 

tranflag chard), N 

equation varchar (200) , 

ref lag chard) , 0 

numflag char(l) , Y 

list_disp_aliaa char (40) 

) ; 



Derived Column 
columnid 
( 

colid integer, 61 

ia_name varchar (40) , % Min 

ia_mdL_nama varchar (40), C5C::% Min 

rptmgr H name varchar (4 0) , % Min 

£ormat_columna chard) , Y 

rpttype char(l) , I 

fact_dim_f lag chard), F 

subtotalflag chard) , U 

tranflag chard) • N 

equation varchar (200) , ( C36 / CT36 ) * 100 

ref lag chard) , 0 

numflag chard] I. Y 
li3t_diap_alias char(40) 



colid 
i a_name 
ia_jnd_name 
rptmagr_name 

f orroat_columns 
rpttype 

f act_dim_f lag 
subtotalflag 



Column "Identifier 
Used by Decision Suite 
Used by Decision Suite. 

The name by which report manager recognizes the column. Not 
used by ODS 

Possible Values :«Y' ■ yes, 1 N 1 « No 

1 Y ■ « invoke the equation. •N 1 » Do not invoke the equation. 
Possible Values: 1 1 1 » Inbound, '0' * Outbound, • D 1 « Doth. 
This indicates if the report is for inbound or outbound calls, 
or both. 

* Possible values 1 F 1 » Fact, 'D 1 « Dimension 
This refers to the type of database table. 
Possible Values 1 Y 1 « Yes, 'N 1 « No. 
Indicates if subtotaling or totaling is required. 
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t--naflag Possible Valuoa «V - Yea, 'N' - No 

C 9 indicates if the translation table needs to be referenced, 

equation The equation to be invoked, should the f ormat_columna field = 

•Y' 

reflag Possible Values »L< « Mat, '0' - OLAP. 

* Indicates if the report is a detail report (List) or a summarj 

report (OLAP) 

numflag Possible Valuae 'y « Yea, «N' - No. 

Indicates if the value is numeric or character, 
list_disp_alias The name to be displayed on the report. This ia only used foi 
~~ List reports. 



Translation Table 

create table " Informix" . translation 
( 

colid amallint, 114 
value, small in t , 19 
tran_literal char (20) International 

> ; 

colid The column identifier on which a translation is needed 

value The value in the column 

tran_literal The literal value that the 4 value' for a particular 'colid* 

gets translated . 



Request Table 

create table ■♦rformix". request 



( 



request_ld integer, 
mag_jdesc char (8192), 



) ; 



unique_f name char (10) , 
report_dir char (120), 
format_dir char (128), 
inbox_dir char (128), 
inbox_fname char (32) , 
inbox_fsizQ integer, 
entpid char (0 J , 
user id char (20) , 
stdrptld integer, 
userptid char(lO), 
compress chard), 
threshold integer, 
subtotal char (32), 
totalmode char(l), 
nrl_totals char (200) . 
forma t_columns char(200) , 
sort_columna char(32), 
error_code integer, 
error_desc char (120) , 
rpmgr__columns char (64 ) 



8855 

AIU>CENTPID»00025677,USERID»1234,STDRPTrD«101, 

USEIUIPTID«1234 , nEQUESTID«8Q55 , PnODUCT»S , THIIE 
SH0LD-<RECC0UOT*"3 0 0> , COLUMNS<r4 4,36,50,67,61,63,62, 
64 , 65 , 66>, FIIiTERSKBILLIHG-09920046 , ,>,,», SOIIT0Y 
•< 4 4 A> , SCHEDULE- A< START" 1 9 9807300000, END- 199807302 
359>,TIMEZONE-<LAflEL«MDT # OFFSET»6>,TOTAU«DE«2 , SUE 
TOTCOL»<» | 
1044301333 

/usr/users/axsys/mci/reporta 
/usr/users/dss/appl 
/inbox/f iles/odsadm 
1044301333. csv_zip 
282 

00025677 

1234 

101 

1234 

1 

300 



«36, 349 1.70><58, 236. 9 0><67 1 500» 

61,63,62 

44A 



44,36, 58,67,61,63,62, 64,65.66 



reques t_id 



The unique Identifier for the request. 
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raag_dC3C 

name assigned to 



report_dir 

forma t_ dir 

inboK_dir 

inbox_f size 
antpid 

userid 
stdrptid 

userptid ' 
compress 

threshold 

subtotal 

totalroode 

nrl_totala 

forma t_columns 

error_code 

errbr_desc m 
rpmg r_cd 1 uriin s 



This is a copy of the ARD message. unique_f name The unique 
each request* This is assigned no 
we can keep track of individual requests. 
It is also assigned to the report returned to the report 
manager. 

The location of the report Decision Suite generates. This is 
the tab delimited report file. 

The location where the report Formatter generates. This is 
the comma delimited file 

The location on the Inbox (Report Manager) where the report is 
sent. 

The size of the file. 

Enterprise id. An enterprise can consist of one or more 
corporate id's 

An identifier assigned to each user of the system. 
Identifies each report. Similar to column id* a bur on the 
report level. 

The user -assigned identifier for a report request. 

Possible Values '1' » yes, '2' - no. Defines if a report is 

to be compressed, using a standard .zip routine. 

Defines the number of lines that shall appear on the report. 

Not used" 

Defines how the report shall be totaled, subtotaled. 
Possible values *0* -No total, Mo subtotal; '1* - Only 
Subtotal; '2* - Only Total; *3' - Total and Subtotal. 
Formatter totals the columns specified in the .hdr file. 
These columns are numeric and have a subtotal flag « 'y* in 
the column id table. 

Defines derived columns on which percentages are to be 
calculated. 

Codes for Parser failure or system failure. If it's a parser 
failure condition, the code is returned to Report Manager. 
Error description. Used only for analysis* 

These are the columns sent to us by Report Manager. Formatter 
checks this list against the list in the .hdr file. 



Request Status Table 

create table •Informix" . req_otatufl 



( 



request_id integer, 
status char (20) , 
priority chard), 
starttime datetime year to second 



010 

*now_mcasage 1 
1 

1999-09-02 17:04:24 



requested 
status 



Priority 
starttime 



The unique identifier for the request. 
Possivle Vales l new_mesaage l , *parser_success ' ( 
parser_JE ailed' , •In.JUlDA 1 , 'ARD\_sent', 'In_IAIO», 

• IAIO_cort4>lete • , « iAIO_f ailed • , 

• in_precf ormat 1 , ' pre_f ormat_comple te 1 , • In_f ormatter 1 , 

forma t ter„coraplete ' , • forma tter_f ailed' , 1 IN_f tp' , ■ f tp_success 1 , 
•ftp_failed' , »IN_nrl, 'nrl_senf , 'nrl_failed' 

Each process updates the request status table as it processes. 
Always ' 1 ' . Not used by 0DS 

The time each process stated work on the request. 
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WHAT IS CIAIMEP IS : 



1 1. A Web/Internet based reporting system for 

2 communicating data information from an enterprise 

3 intranet database to a client workstation via an 

4 integrated interface, said system comprising: 

5 client browser application located at 

6 said client workstation for enabling interactive 

7 Web based communications with said reporting 

8 system, said client workstation identified with a 

9 customer and providing said integrated interface; 

10 at least one secure server for managing 

11 client sessions over the Internet, said secure 

12 server supporting a first secure socket connection 

13 over a first firewall enabling encrypted 

14 communication between said client browser 

15 application and said secure server; 

16 report manager server for maintaining an 

17 inventory of reporting items associated with a 

18 customer and managing the reporting of customer - 

19 specific data information in accordance with a 

20 customer report request message, said report 

21 manager generating a response message including a 

22 metadata description of said reporting items 

23 included in a report request; 

24 dispatch server for communicating with 

25 said secure server through a second firewall over a 

26 second socket connection, said first secure and 

27 second socket connections forming a secure 

28 communications link, said dispatch server enabling 

29 forwarding of a report request message to said 

30 report manager server; and 

31 operational data storage device for 

32 receiving a metadata description of a requested 
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1 report from said report manager server and 

2 retrieving said customer- specific data from said 

3 enterprise intranet database in accordance with 

4 said received metadata description; 

5 wherein said retrieved data and said 

6 metadata description of said reporting items are 

7 utilized to generate a completed report for 

8 presentation to said customer via said interface. 

1 2. The reporting system as claimed in Claim 

2 1, further including client report requestor 

3 application for enabling presentation of a report 

4 request menu including various reporting options 

5 for said customer in accordance with predetermined 

6 customer entitlements, said reporting options 

7 including creation and customization of said 

8 reporting items. 

1 3. The reporting system as claimed in Claim 

2 2, wherein said client report requestor 

3 application further generates said report request 

4 message in response to user selection of a specific 

5 report option for communication over said secure 

6 communications link, for receipt by said report 

7 manager server. 

1 4. The reporting system as claimed in Claim 

2 2, wherein said second operational data storage 

3 device for accessing customer- specif ic data 

4 includes a mechanism for formatting said customer- 

5 specific data information in accordance with said 
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metadata description, said customer- specif ic data 
being formatted for display at said client 
workstation via said integrated interface. 

5. The reporting system as claimed in Claim 
2, further including report scheduler server for 
enabling said operational data storage device to 
retrieve said customer -specific data at 
predetermined times in accordance with a reporting 
schedule. 

6. The reporting system as claimed in Claim 

5, wherein said scheduler server enables said 
operational data storage device to retrieve said 
customer- specif ic data at a customer- specif led 
frequency. 

7. The reporting system as claimed in Claim 

6, wherein said report manager server includes a 
process for generating requestor applets for 
communication over said secure communications link 
to said client workstation, one of said applets 
capable of presenting said reporting items to a 
requesting customer via said interface. 

8. The reporting system as claimed in Claim 
1, wherein said customer specific data information 
relates to priced call detail data representing 
usage of a customer's telecommunications network. 
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1 9. The reporting system as claimed in Claim 

2 1, wherein said enterprise intranet database is 

3 organized as one or more datamart storage devices, 

4 said operational data storage device determining 

5 one or more specific datamart storage devices from 

6 which to access said customer- specific data 

7 information in accordance with a report metadata 

8 description. 

1 10. The reporting system as claimed in Claim 

2 9, further including a data harvester device for 

3 periodically inputting up-to-date data information 

4 into said one or more datamart storage devices. 

1 11. The reporting system as claimed in Claim 

2 10, wherein said one or more datamart storage 

3 devices is organized according to a star- schema 

4 topology to facilitate retrieval of customer - 

5 specific data therefrom. 

1 12. The reporting system as claimed in Claim 

2 1, further including isubscribe and publish 

3 communications interface between said report 

4 manager server and said operational data storage 

5 device, said metadata descriptions being translated 

6 by said report manager server to generate published 

7 messages for receipt by said operational data 

8 storage device. 

1 13. The reporting system as claimed in Claim 

2 1, further including a client report viewer 
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1 application for receiving said customer specific 

2 data of a requested report and a metadata 

3 description of a report type and generating said 

4 report for display at said interface. 

1 14. A method for reporting data information 

2 from an enterprise intranet database to a client 

3 terminal via an integrated interface, said system 

4 comprising: 

5 enabling interactive Web based 

6 communications between said client terminal 

7 identified with a customer and a first secure 

8 server over a first secure socket connection, said 

9 socket connection enabling encrypted communication 

10 between said browser application client and said 

11 secure server; 

12 enabling communications between said 

13 secure server and a second server over a second 

14 socket connection, said first and second sockets 

15 forming a secure communications link, said second 

16 server enabling forwarding of a report request 

17 message and an associated report response message 

18 back to said client browser over said secure 

19 communications link; 

20 accessing reporting items based on a 

21 customer identity and report name from a first 

22 database, and generating a response message 

23 including a metadata description of said reporting 

24 items; 



-152- 



SUBSTITUTE SHEET (RULE 26) 



WO 99/16207 



PCT/US98/2014S 



1 retrieving said customer -specific data 

2 from said enterprise intranet database in 

3 accordance with said metadata description; and, 

4 generating a completed report for said 

5 customer from said metadata description of said 

6 reporting items and said accessed customer- specif ic 

7 data via said interface • 

1 15. The method as claimed in Claim 14, 

2 further including the step of presenting a report 

3 request menu including various reporting options 

4 for said customer in accordance with predetermined 

5 customer entitlements, said reporting options 

6 including creation and customization of said 

7 reporting items. 

1 16. The method as claimed in Claim 14, 

2 further including the step of generating said 

3 report request message in response to user 

4 3election of a specific report option for 

5 communication over said secure communications link, 

6 and communicating a response message over said 

7 communications link for display at said client 

8 terminal . 

1 17. The method as claimed in Claim 15, 

2 wherein said step of accessing customer- specific 

3 data includes the step of formatting said customer- 

4 specific data information in accordance with said 

5 metadata description, and storing said customer - 

6 specific data information in a database. 
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1 18. The method as claimed in Claim 17, 

2 further including the step of enabling retrieval of 

3 said customer -specific data at a predetermined time 

4 in accordance with a reporting item. 

1 19, The method as claimed in Claim 15, 

2 further including periodically enabling retrieval 

3 of said customer- specif ic data, 

1 20. The method as claimed in Claim 18, 

2 further including generating requester applets for 

3 communication over said secure communications link 

4 to said client terminal, said applet presenting 

5 said reporting items to a requesting customer via 

6 said interface. 

1 21. The method as claimed in Claim 15, 

2 wherein said enterprise intranet database is 

3 organized as one or more datamarts, said method 

4 including determining one or more specific 

5 datamarts from which to access said customer - 

6 specific data information. 
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